Sizes of libraries/archives increase?

Hello,

when comparing the sizes of 32 bit libraries/archives built with ftn95 version 7.10 and with ftn95 version 8.60 we observed that the sizes of some libraries increased significantly from version v7.10 to version 8.60.

Some libraries increased by a factor greater 5 and this makes me wonder.

Has anyone else observed this, too?

I don't have any clue why this happens.

Thanks for any information Dietmar

Are you, by chance, comparing libraries of 32-bit objects produced by Version 7.1 and libraries of 64-bit objects produced by Version 8.6?

Or maybe comparing 'release' code with 'checkmate' code?

mecej, Paul,

I'm afraid no.

I built from within a CMD window using command

ftn95 <file_basename> /ALL_WARNINGS/NON_STANDARD/SINGLE_THREADED/OLD_ARRAYS/ALT_KINDS/PERSIST/ZEROISE/UNLIMITED_ERRORS/FIXED_FORMAT/SAVE/NO_WARN73/WIDE_SOURCE /WINDOWS  /MKLIB /include ..;..\..\subinc /Cfpp  /DEFINE SALFORD 1

for both the v7.10 and the v8.60 case thus generating libraries <file_basename>.lib.

For both libraries I could execute command

slim /list <file_basename>.lib>

which I would not have been able for a 64 bit library (this would result in an error '*** could not open <filename>.obj', wouldn't it?). For v7.10 this resulted in output

[Salford SLIM/Win32 v1.0, Copyright (c) Salford Software Ltd. 2004]
<file_basename>.LIB [Archive]
    <file_basename>.obj [1228 bytes]
    <file_basename>.obj [646 bytes]
    <file_basename>.obj [35560 bytes]
    <file_basename>.obj [42860 bytes]
    <file_basename>.obj [1018 bytes]
    <file_basename>.obj [46972 bytes]
    <file_basename>.obj [2634 bytes]
    <file_basename>.obj [3390 bytes]
    <file_basename>.obj [1258 bytes]
    <file_basename>.obj [37124 bytes]
    <file_basename>.obj [35040 bytes]
    <file_basename>.obj [588 bytes]
    <file_basename>.obj [2238 bytes]
    <file_basename>.obj [5368 bytes]
    <file_basename>.obj [1768 bytes]
    <file_basename>.obj [1244 bytes]
    <file_basename>.obj [1262 bytes]
    <file_basename>.obj [1584 bytes]

for v8.60 in

[Salford SLIM/Win32 v1.0, Copyright (c) Salford Software Ltd. 2004]
<file_basename>.LIB [Archive]
    <file_basename>.obj [1228 bytes]
    <file_basename>.obj [1262 bytes]
    <file_basename>.obj [36184 bytes]
    <file_basename>.obj [75766 bytes]
    <file_basename>.obj [64626 bytes]
    <file_basename>.obj [110620 bytes]
    <file_basename>.obj [97858 bytes]
    <file_basename>.obj [99270 bytes]
    <file_basename>.obj [98002 bytes]
    <file_basename>.obj [133924 bytes]
    <file_basename>.obj [162920 bytes]
    <file_basename>.obj [159196 bytes]
    <file_basename>.obj [160846 bytes]
    <file_basename>.obj [164640 bytes]
    <file_basename>.obj [161744 bytes]
    <file_basename>.obj [161892 bytes]
    <file_basename>.obj [162534 bytes]
    <file_basename>.obj [163480 bytes]

Moreover I found string 'ftn95 7.10.0' in the library built with version 7.10 and did not find string '8.60.0' in it. And I found string 'ftn95 8.60.0' in the library built with version 8.60 and did not find '7.10.0' in it. The size of the library is

223.628 for v7.10.0
2.017.838 for v8.60.0

(retrieved via dir command).

You see that files 4 in both list differ significantly (42860 in v 7.10.0 oppsosite to 75766 in v8.60.0). I do not know precisely but I suppose that the first entry in the lists generated via slim refer to the first subroutine/function of the corresponding *.for file, that the second entry in the lists refer to the second subroutine/function and so on. Could you please confirm that? Now I generated a library with ftn95 v 8.60.0 from a *.for file containing only the fourth subroutine/function in the sample above. The result of the slim command for this library was

[Salford SLIM/Win32 v1.0, Copyright (c) Salford Software Ltd. 2004]
fowngrwb.LIB [Archive]
    <file_basename.obj [42838 bytes]

Unfortunatly I cannot create a reproducer yet. Currently I can only tell you that function four of the original/first sample above contains an ENTRY startement.

Regards, Dietmar

I can't think of anything that might cause this to happen. SLIM has not changed and the code in FTN95 that calls SLIM does not appear to be different.

Presumably the two builds are done on the same machine.

SLIM archives the object code via concatenation so maybe somehow you are getting multiple copies within the archive. Reading the archive in a binary editor might reveal this or maybe dumpbin.exe might give useful information (if you have it).

If you can't find the origin of the problem then here are two possible ways forward:

1. Send me your project to look at.

2. Change from using SLIM to use the archive feature in SLINK.

If both archives contain 32-bit OBJs, we are well situated to diagnose the problem. Extract the last OBJ file in each of the two archives. According to the listing that you showed, it is 1.6 kbytes in one and 163 kbytes in the other. The file sizes of the extracted files should also differ by a factor of about 100.

Post the source code that when compiled produced these OBJ files.

Sorry, my last entry has been cut. Here is the continuation:

Now I generated a library with ftn95 v 8.60.0 from a *.for file containing only the fourth subroutine/function in the sample above. The result of the slim command for this library was

  for version 7.10.0
[Salford SLIM/Win32 v1.0, Copyright (c) Salford Software Ltd. 2004]
c:\ds_tmp\lib32\sample_size_libs_1.lib [Archive]
    sample_size_libs_1.obj [42832 bytes]

and

 for version 8.60.0
[Salford SLIM/Win32 v1.0, Copyright (c) Salford Software Ltd. 2004]
c:\ds_salford_8.60\lib32\sample_size_libs_1.lib [Archive]
    sample_size_libs_1.obj [42856 bytes]

. This is a difference I would not worry about.

Regards, Dietmar

Does that mean the problem is solved?

Paul,

no, if adding routine 3 of the big sample I mentioned above to the small sample then the problem occurs again.

I currently try to break my sample down to fortran code which I can send you.

I have a question concerning the way how I would extract an object file from a library. Assume a fortran file consisting of two routines, say sample_size_libs.for. Build a library via the ftn95 command mentioned above, i.e. with /mklib in use. Command

slim /list sample_size_libs.libs

gives the output

 for v8.60.0
    sample_size_libs.obj [35586 bytes]
    sample_size_libs.obj [75168 bytes]

and

 for v7.10.0
    sample_size_libs.obj [35578 bytes]
    sample_size_libs.obj [42878 bytes]

In the 8.60.0 case I used command

lib sample_size_libs.LIB /EXTRACT:sample_size_libs.obj /OUT:sample_size_libs.obj

which creates object file sample_size_libs.obj of size 35.585 for v8.60.0 ; this size correlates to the size of the first entry listed above for v8.60.0. Now, how would I extract the object file corresponding to the second entry for v8.60.0 (corresponding to size 75168)?

Regards, Dietmar

Dietmar

I don't think there is a simple way to extract a block of object code from an archive. But then, I don't understand why you would want to do that. Why not just store the original .obj files separately?

Perhaps if you can send me a cut down project then I will be better able to understand what you are doing and why it has gone wrong.

Paul,

we use to build libs using ftn95 compile option /mklib. Now quoting from your online help:

/MKLIB Win32 only. Generates a static library containing a separate object for each function or subroutine. /MKLIB causes FTN95 to call the Salford library manager called SLIM. Objects in the resulting static library may work correctly with the debugger SDBG. The use of SLIM objects with SDBG is not supported.

I am very confused. The lists generated from comand 'slim /list' show several entries with **one **object file name for **every **entry. My sample sample_size_libs.for contains 2 routines. Via command

lib sample_size_libs.LIB /EXTRACT:sample_size_libs.obj /OUT:sample_size_libs.obj

file sample_size_libs.obj is extracted from sample_size_libs.lib; via command

dumpbin /SYMBOLS sample_size_libs.obj

I may see the symbols in file sample_size_libs.obj. However, there is no symbol corresponding to the second routine of file sample_size_libs.for marked as defined in this dump, only the first routine of sample_size_libs.for is marked as defined (if I interpret the list correctly). Now how would I extract the object file of the second routine (which internally must exist)?

Mecej4 suggested:

Extract the last OBJ file in each of the two archives.

but that seems to be impossible, if using /mklib when building the library. The extraction from the library is done to get information about the contents of the files contained in the library. When building library sample_size_libs.lib with option /mklib I do not see any object file sample_size_libs.obj.

As I said in a previous entry of this post I will create a short example consisting of only two routines to see what happens.

Regards, Dietmar

Dietmar

I don't need this information right now but when you send me the sample can you also describe what you do with the resulting static library that you generate via /MKLIB and SLIM. For example, does the resulting static library appear in a SLINK script for building an exe or dll?

This turns out to be a regression which we are aiming to fix. Somehow the /SAVE option is causing PARAMETER constants within INCLUDE <windows.ins> to be SAVEd by mistake.

A work-around is to replace INCLUDE <windows.ins> by USE mswin.

This was a regression at v7.20 that has now been fixed for the next release.

The fault occurs when using /SAVE and when the PARAMETER attribute is given in a separate statement after the type of the variable has been declared..

Paul,

thanks for your help and of course the fix.

I'm looking forward to the next release 😃

Regards Dietmar