Silverfrost Forums

Welcome to our forums

FTN95 with Visual Studio - adding libs

31 Oct 2011 5:29 #9161

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,

31 Oct 2011 8:01 #9162

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.

31 Oct 2011 1:56 #9166

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.

1 Nov 2011 7:02 #9170

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.

1 Nov 2011 8:56 #9171

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.

1 Nov 2011 4:39 #9172

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.

2 Nov 2011 2:29 #9173

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

2 Nov 2011 3:41 #9174

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.

3 Nov 2011 1:09 #9177

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 SECT5 notype Static | .salfdbg

String Table Size = 0x0 bytes

And in the slink map file I see: 00400000 header Linker defined

Address Name File in which defined ... 008592b0 SIMPLX ...

If I then put my LINV subroutine, and put it in the simplx.for file (which is in the same static library as linv.for), the subroutine LINV will be resolved. Although this strange behaviour does seem to workaround the problem, as I have lots of these instances, it is not very pratical.

Is there a way that SLINK can output some more debug on what it might be doing ?

3 Nov 2011 1:28 #9178

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,

3 Nov 2011 8:36 #9180

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

Please login to reply.