forums.silverfrost.com

[Nathan]

I am having problems with unresolved externals when adding libs and using VS2005 or 2010. This is a win32 library and executable, not .NET.

My first problem is that both editions of Visual studio crash when I try to add a reference, and browse to the library. I can get around this by adding a project instead. So I now build the library in VS as well, and can add the library as a reference this way.

However, I still can not resolve the externals. I have tried adding the libs as well in the linker options in the exectable project. I just can't see what else could be going wrong. I can build the project and libraries fine using ftn95 and makefiles, and to me, the linker command line looks almost identical. It is just when using ftn95 and visual studio. All projects are built with the same options as far as I can tell.

Has anyone successfully done this sort of thing using libaries and visual studio ?

Thanks,

[PaulLaidler]

Resolving missing externals is independent of the IDE (Visual Studio or Plato) or makefile that you use.

You need to find out where the missing externals are located and then import the relevant DLL or LIB into the linker. It is also important to note that DLLs sometimes come with an associated LIB that contains only "stubs" or headers for the routines. These provide information for a linker. The body of the code will then be in the DLL and accessed at runtime. SLINK does not normally need to use stub libraries. It can get the information directly from the DLL.

[Nathan]

Thanks Paul.

How do I import the library into the linker ? And in Visual Studio.

Is this different to either in Visual Studio adding a reference, or in the linker options, adding the library file as an extra switch. From looking at the makefile, it seems that I just add all the library dependencies as file names to the linker.

[PaulLaidler]

The basic information is in the help file ftn95.chm under Win32 platform->Using the linker.

You can see what the IDE (Visual Studio or Plato) is doing for you by looking at the build log that the IDE creates for each build process.

The appropriate SLINK commands depend on whether you are linking to a DLL or with a static LIB.

[Nathan]

Hi Paul

Thanks for your reply.

What I am trying to acheive is including several static libraries, all of which use subroutines within other static libraries, and then link them all togeather into an exe.

I believe some of my troubles may be because I can not create a static library project directly in Visual Studio. It lets me create an application extension, which is of type dll. In the properties of the project, I have then turned this into a static library. But I do not seem to be able to use the -addobj command using the visual studio IDE. This may be needed. Basically, what I am finding is that some symbols are resolved and others are not. I am going through the build logfiles and all seems the same between using the makefile and using the IDE, but something is not quite right. The only difference I have so far spotted is the lack of addobj.

[PaulLaidler]

I have had a quick look at Visual Studio and it appears that must first create an application extension and then change the project properties so that the outuput file type (under Compiler options->Miscallaneous) is changed to Import Lib.

Check the build log to see if this uses addobj as required.

If it does not work, try Plato where you can create a static library project from the outset.

[Nathan]

Hi Paul

Thanks for your help so far with my lib problem.

As far as I can tell, all my code has been included in the static lib file. When I run dumpbin /symbols I can see the function name, with a leading underscore.

Then looking at the logfile, I can see that slink is called, with the library, but for some reason, some of the symbols within the library can be resolved, and others not. The ones that are resolved, look just the same when using dumpbin on the lib as the ones that are unresolved.

Is there a way to be able to turn on some extra debugging that slink is doing to see if it gives any more indications as to what is happenning. I am wondering if i am hitting some limits as my project contains over 20 static libs, some of which have over 100 object files. When i create a simple example, of course, everything works just fine.

Any other ideas. I don't think it is much to do the IDE I am running(VS), as I since seen that addobj is being used by the linker for the static libs, it was just put in a list.lst file and called it on to the slink command line in that way. Anyway, the fact that dumpbin shows the symbols in the libraryis indicating that the libraries are being linked properly. What is most strange is that some symbols in the library are being resolved and others not.

Thanks,
Nathan

[PaulLaidler]

Have you had a look at the SLINK map file obtained by selecting "Output map file" in the "Linker options"?

If there are problems with mismatched "decorations" to the names of routines, then the map file may show this.

[Nathan]

Yes, I am looking at the map file, logfiles and using dumpbin.

Essentially my problem can be explained by if I use dumpbin /symbols on the library, I see the symbol defined. For example looking at LINV
COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
LINV.FOR
005 00000000 SECT5 notype Static | .salfdbg
Section length 400, #relocs 0, #linenums 0, checksum 0
007 00000000 SECT1 notype Static | .text
Section length 3F0, #relocs 2A, #linenums 2C, checksum 0
009 00000000 SECT2 notype Static | .data
Section length 240, #relocs 0, #linenums 0, checksum 0
00B 00000000 SECT1 notype () External | _LINV
tag index 0000000D size 000002B0 lines 00000000 next function 00000013
00D 00000000 SECT1 notype BeginFunction | .bf
line# 0002 end 00000015
00F 00000000 SECT1 notype EndFunction | .ef
line# 003a
011 00000000 SECT5 notype Static | .salfdbg
012 00000000 UNDEF notype () External | _XXJJ##
013 000002B0 SECT1 notype () External | _EI1
tag index 00000015 size 00000140 lines 00000000 next function 00000000
015 000002B0 SECT1 notype BeginFunction | .bf
line# 003c end 00000000
017 00000000 SECT1 notype EndFunction | .ef
line# 0057
019 00000242 SECT5 notype Static | .salfdbg
01A 00000000 UNDEF notype () External | _EXP#X
01B 00000000 UNDEF notype () External | _ALOG#X

String Table Size = 0x0 bytes

But then if I look at the map file of the exe where I am linking in the library I see

Unresolved external references
LINV ...


But then other symbols in the same library are resolved. If I try moving the LINV function to a different file that does seem to contain symbols that are resolved, then suddenly LINV is also resolved. Which makes me think that its nothing to do with LINV, more to do with something going wrong during SLINK in certain instances.

For example in the same library, I have

COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
SIMPLX.FOR
005 00000000 SECT5 notype Static | .salfdbg
Section length 830, #relocs 0, #linenums 0, checksum 0
007 00000000 SECT1 notype Static | .text
Section length D30, #relocs 1C, #linenums 9A, checksum 0
009 00000000 SECT2 notype Static | .data
Section length 30, #relocs 0, #linenums 0, checksum 0
00B 00000000 SECT1 notype () External | _SIMPLX
tag index 0000000D size 00000780 lines 00000000 next function 00000015
00D 00000000 SECT1 notype BeginFunction | .bf
line# 0004 end 00000017
00F 00000000 SECT1 notype EndFunction | .ef
line# 00c6
011 00000000 SECT5 notype Static | .salfdbg
012 00000000 UNDEF notype () External | _SIMP1
013 00000000 UNDEF notype () External | _SIMP3
014 00000000 UNDEF notype () External | _SIMP2
015 00000780 SECT1 notype () External | _SIMP1
tag index 00000017 size 00000160 lines 00000000 next function 0000001C
017 00000780 SECT1 notype BeginFunction | .bf
line# 00c8 end 0000001E
019 00000000 SECT1 notype EndFunction | .ef
line# 00e4
01B 00000365 SECT5 notype Static | .salfdbg
01C 000008E0 SECT1 notype () External | _SIMP2
tag index 0000001E size 000002A0 lines 00000000 next function 00000023
01E 000008E0 SECT1 notype BeginFunction | .bf
line# 00e5 end 00000025
020 00000000 SECT1 notype EndFunction | .ef
line# 0112
022 000004DB SECT5 notype Static | .salfdbg
023 00000B80 SECT1 notype () External | _SIMP3
tag index 00000025 size 000001B0 lines 00000000 next function 00000000
025 00000B80 SECT1 notype BeginFunction | .bf
line# 0113 end 00000000
027 00000000 SECT1 notype EndFunction | .ef
line# 0131
029 000006EA SECT

[Nathan]

ABOVE POST CONTINUED:

And SIMPLX appears in the map file as resolved. The files SIMPLX.for and LINV.for are in the same library. If I then take the subroutine called linv from linv.for and add it to simplx.for, the suddenly linv is resolved.

Although this workaround seems to work for some reason, it is not pratical as I have many instances of this problem.

Is there a way I can produce more debug from slink.exe to tell me what what could be going wrong ?

Thanks,

[PaulLaidler]

Can you post the relevant parts of the SLINK map files that refer to a missing external.