Fail to link 64-bit Code

Fail to link 64-bit Code

I have a working 32-bit software library written in Fortran with low-level stuff in C/C++ It has worked for years.

It is fine.

When I re-build the library in 64-bit mode, none of the C functions are linked in. I've checked the linker options, and they all seem to be right. The project appears to be referencing the 64-bit libraries.

Would someone mind just looking some sample  INTERFACE code and tell me whether there is anything at all that would cause a problem 

      SUBROUTINE PBZQS(MODE, IXORIG, IYORIG, NX, NY)
      INTEGER MODE
      INTEGER IXORIG, IYORIG
      INTEGER NX, NY

      INTERFACE
        SUBROUTINE JB_ZBSpecInquireImageSize(MODE, IXORIG, IYORIG, NX,
     1      NY)
          INTEGER MODE
          INTEGER IXORIG, IYORIG
          INTEGER NX, NY
          !DEC$ ATTRIBUTES C, ALIAS: '_JB_ZBSpecInquireImageSize' ::
     1      JB_ZBSpecInquireImageSize
          !DEC$ ATTRIBUTES VALUE :: MODE
          !DEC$ ATTRIBUTES REFERENCE ::  IXORIG, IYORIG, NX, NY
        END
      END INTERFACE

      CALL JB_ZBSpecInquireImageSize(MODE, IXORIG, IYORIG, NX, NY)
      END

The linker comes up with:unresolved external symbol'_JB_ZBSpecInquireImageSize

Reassurance from someone "that should work" is all I need.

 

I observe that the project includes the library comdlg32.lib. Is that going to be right for a 64-bit application?

Is there an easy way to look at the contents of the .lib file that is being linked in?

7 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di mecej4

Did you recompile your C library with a 64-bit C compiler? What does the prototype declaration of JB_ZBSpecInquireImageSize show?

The system libraries such as comdlg32.lib are available in 32-bit and 64-bit versions, and the 32-bit versions will be located in a different directory from the 64-bit version, You need to link against the 64-bit versions. 

Ritratto di Lorri Menard (Intel)
Best Reply

The naming conventions are different for Windows running on a 32-bit system than for Windows running on a 64-bit system.
On 32-bit, the external names are prefixed with an underscore; on 64-bit they are not.

If you can't use the standard BIND(C) mechanism, please try changing this line:

!DEC$ ATTRIBUTES C, ALIAS: '_JB_ZBSpecInquireImageSize'

to this:

!DEC$ ATTRIBUTES C, decorate, ALIAS: 'JB_ZBSpecInquireImageSize'

What I did was remove the explicit leading underscore, and added the keyword "decorate".   This tells the compiler to apply the prevailing naming convention to the string specified in the ALIAS clause.

Of course, using the standard BIND(C) mechanism would be better, but would require a few more edits than this one line.  
     But just a few.

                    --Lorri

Quote:

mecej4 wrote:

Did you recompile your C library with a 64-bit C compiler? What does the prototype declaration of JB_ZBSpecInquireImageSize show?

The system libraries such as comdlg32.lib are available in 32-bit and 64-bit versions, and the 32-bit versions will be located in a different directory from the 64-bit version, You need to link against the 64-bit versions. 

Thanks for your help.

I think the library is compiled with the 64-bit compiler -the Platform x64 is selected, and stuff goes into x64 directories.

I had a walk down memory lane and located the header file containing declarations.

Here is the definition of JB_ZBSpecInquireImageSize:

extern void JB_ZBSpecInquireImageSize(const int mode, int *iXOrig, int *iYOrig, int *nX, int *nY);

Do you mean that as long as I'm linking within the 64 bit environment I don't need to change comdlg32 to comdlg64, and that's not anything to do with the linker problem?

Quote:

Lorri Menard (Intel) wrote:

 

The naming conventions are different for Windows running on a 32-bit system than for Windows running on a 64-bit system.
On 32-bit, the external names are prefixed with an underscore; on 64-bit they are not.

 

If you can't use the standard BIND(C) mechanism, please try changing this line:

 

 

!DEC$ ATTRIBUTES C, ALIAS: '_JB_ZBSpecInquireImageSize'

 

 

to this:

 

 

!DEC$ ATTRIBUTES C, decorate, ALIAS: 'JB_ZBSpecInquireImageSize'

 

 

What I did was remove the explicit leading underscore, and added the keyword "decorate".   This tells the compiler to apply the prevailing naming convention to the string specified in the ALIAS clause.

 

 

Of course, using the standard BIND(C) mechanism would be better, but would require a few more edits than this one line.  
     But just a few.

 

 

                    --Lorri

Yippee!! That did the trick for the 1st of 53 missing externals, and I'll now start on the other 52. Thanks for the explanation

I will use the Bind(C) approach unless that has its own pitfalls. This will entail reviewing code written 15 years ago in a language not used for 14 years. Any pointers to "Best definition" of interface conventions will be welcome.

And I suppose Fortran 77 (I started on Fortran IV and still remember Fortran II with its cunning GOTOs) will have to give way to Fortran 9x

But thanks. You are a wonderful woman (as no doubt you are tired of hearing)

 

Ritratto di mecej4

Quote:

David B. wrote:
Do you mean that as long as I'm linking within the 64 bit environment I don't need to change comdlg32 to comdlg64, and that's not anything to do with the linker problem?

Exactly. On Windows X64 (XP, Vista, 7, 8, 8.1) the 64-bit system utilities (DLLs, EXEs and drivers) are located in Windows\System32, whereas the 32-bit system utilities are in Windows\SysWow64. Please do not ask me if that is logical!

Quote:

Is there an easy way to look at the contents of the .lib file that is being linked in?

Dumpbin /symbols xx.lib.

Dumpbin /exports yy.dll.

Quote:

mecej4 wrote:

Quote:

David B. wrote:Do you mean that as long as I'm linking within the 64 bit environment I don't need to change comdlg32 to comdlg64, and that's not anything to do with the linker problem?

Exactly. On Windows X64 (XP, Vista, 7, 8, 8.1) the 64-bit system utilities (DLLs, EXEs and drivers) are located in Windows\System32, whereas the 32-bit system utilities are in Windows\SysWow64. Please do not ask me if that is logical!

Quote:

Is there an easy way to look at the contents of the .lib file that is being linked in?

Dumpbin /symbols xx.lib.

Dumpbin /exports yy.dll.

And you are a lovely lad. As your mother always said.

I'm now sorted - until the next pitfall. Thanks

Accedere per lasciare un commento.