forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Sizes of libraries/archives increase?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 230

PostPosted: Tue Mar 03, 2020 12:45 pm    Post subject: Sizes of libraries/archives increase? Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1328

PostPosted: Tue Mar 03, 2020 12:53 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6386
Location: Salford, UK

PostPosted: Tue Mar 03, 2020 1:33 pm    Post subject: Reply with quote

Or maybe comparing "release" code with "checkmate" code?
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 230

PostPosted: Tue Mar 03, 2020 3:41 pm    Post subject: Reply with quote

mecej, Paul,

I'm afraid no.

I built from within a CMD window using command
Code:

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
Code:

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
Code:

[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
Code:

[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
Code:

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
[code:1:bc0cb86556]
[Salford SLIM/Win32 v1.0, Copyright (c
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6386
Location: Salford, UK

PostPosted: Tue Mar 03, 2020 4:33 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1328

PostPosted: Tue Mar 03, 2020 4:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 230

PostPosted: Wed Mar 04, 2020 10:18 am    Post subject: Reply with quote

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
Code:
  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
Code:
 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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6386
Location: Salford, UK

PostPosted: Wed Mar 04, 2020 10:55 am    Post subject: Reply with quote

Does that mean the problem is solved?
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 230

PostPosted: Wed Mar 04, 2020 12:00 pm    Post subject: Reply with quote

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
Code:

slim /list sample_size_libs.libs

gives the output
Code:
 for v8.60.0
    sample_size_libs.obj [35586 bytes]
    sample_size_libs.obj [75168 bytes]

and
Code:
 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
Code:

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6386
Location: Salford, UK

PostPosted: Wed Mar 04, 2020 12:14 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 230

PostPosted: Wed Mar 04, 2020 2:26 pm    Post subject: Reply with quote

Paul,

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

Quote:

/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
Code:

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
Code:

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:
Quote:

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6386
Location: Salford, UK

PostPosted: Wed Mar 04, 2020 3:40 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6386
Location: Salford, UK

PostPosted: Fri Mar 06, 2020 3:21 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6386
Location: Salford, UK

PostPosted: Sat Mar 07, 2020 8:35 am    Post subject: Reply with quote

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..
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 230

PostPosted: Mon Mar 09, 2020 10:15 am    Post subject: Reply with quote

Paul,

thanks for your help and of course the fix.

I'm looking forward to the next release Smile

Regards
Dietmar
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group