Unresolved External linking 64bit library

[jaeger0]

I compiled a Library for 64bit. In the main programm I tryed to use this library, butlinker failedwith the unresolvedexternal error. For the 32-bit version I have no problems. Where should I look for the error, in the library or in the main programm. Or is there a different naming with 64bit version ?

1>xeffort.lib(XFTListView.obj) : error LNK2001: unresolved external symbol _GetWindowLongA@8

[TimP]

There's no support for stdcall in 64-bit ABI. One would think this would have been flagged earlier.

[Steven_L_Intel1]

The compiler accepts a request for STDCALL but most aspects of it, including naming, are ignored. I think you are linking in a 32-bit library, or one that has explicit ALIAS names that include the decoration, which won't work. GetWindowLong is a Win32 API routine which is properly declared in module USER32.

[jaeger0]

Ok, I think I have a lot of work, since I have a lot of unresolved externals. For GetWindowLong I solved the problem, but I have a lot of functions like

1>XFTFile.obj : error LNK2019: unresolved external symbol _FindFirstFileA@8 referenced in function XFTFILE.

what means @8 behind _FindFirstFileA ?

FindFirstFile is defined by the above interface. How do I convert the interface to 64bit ?

interface

integer(4) function FindFirstFile (lpFileName ,lpFindFileData )

!DEC$ ATTRIBUTES STDCALL, ALIAS : '_FindFirstFileA@8' :: FindFirstFile

!DEC$ ATTRIBUTES REFERENCE :: lpFileName

!DEC$ ATTRIBUTES REFERENCE :: lpFindFileData

use xftapity

character*(*) lpFileName

type(T_WIN32_FIND_DATA) lpFindFileData

end function FindFirstFile

end interface

[Les_Neilson]

!DEC$ ATTRIBUTES STDCALL, DECORATE, ALIAS :'FindFirstFile' :: 'FindFirstFile'

Les

[jaeger0]

Now I get
XFTFile.obj : error LNK2019: unresolved external symbol FindFirstFile referenced in function XFTFILE.

what's the difference to
!DEC$ ATTRIBUTES STDCALL, ALIAS : '_FindFirstFileA@8' :: FindFirstFile
which worked fine on x86

[Jugoslav_Dujic]

Hello,
It won't be so easy to port Xeffort to 64-bit, although I would appreciate your eXtra effort :)

I foresee the following problems (note that I'm speaking from memory, so bear with me if I make an error)

1. The most easy one: You should replace all occurrences of
   !DEC$ ATTRIBUTES STDCALL, ALIAS : '_FindFirstFileA@8' :: FindFirstFile
   with
   !DEC$ ATTRIBUTES STDCALL, DECORATE, ALIAS : 'FindFirstFileA' :: FindFirstFile
   It was done that way because CVF 6.0 (which was an early development platform) did not support DECORATE attribute, which makes it portable between 32 and 64-bit platforms.
2. Much more serious one is that all addresses in Xeffort code (and INTERFACEs) are implicitly 32-bit, but they are not consistently indicated as such. Since I usually used light Hungarian notation, they start with p or lp. However, Win64 HANDLE-s are also 64-bits (right?) so all variables starting with h should also be integer(HANDLE).
   I have an old fork of the library on my disk, which uses ISO_C_BINDING types throughout (the aim was to port to G95/GFortran); however, it is not finished and I don't guarantee its compilability. Attached anyway.

[jaeger0]

Ok I see thats not so easy. How much time do you guess I need. I have one-2 Weeks. Otherwise I will skip that to later on. Do I need to use the ISO_C_Binding types, is that mayby faster to convert.

[Jugoslav_Dujic]

The most boring part of it is to determine which variables should be 64-bit (and unfortunately the code seldom uses kind constants, such as HANDLE, DWORD or LPARAM).

XFTAPI.f90 and XFTAPITY.f90 are, most of the time, copy & pastes from IFWINTY.f90 and IFWIN.f90 modules (plus some stuff not found there). It was done that way because I didn't want to depend on Compaq/Intel's translations of Windows.h (when they change, and that was with every new release, they would very often break Xeffort code). Unfortunately, I didn't pay attention to KINDs at that stage, so the resulting code is stuck with 32-bit (unless kind constants are properly introduced). That, however, does not affect only XFTAPI and XFTAPIty -- all local variables should be also checked for 64-bit compatibility. Compiler will help with some (seeing integer(4)--integer(8) mismatches in API calls), but others will require manual revision.

The sources attached above already use ISO_C_BINDING (although an early version of it) for pointers and references. They should reasonably match the current version of the sources by functionality. Have in mind, though, that the aim was to port to 32-bit Gfortran (and/or Silverfrost FTN95), not to 64-bit Windows: thus, it portably covers only pointers (p and lp) through type(C_PTR and C_FUNPTR) but not other 64-bit stuff. Note, however, that full C interoperability does not play nice with STDCALL -- you cannot use BIND(C) and !DEC$ATTRIBUTES STDCALL together. You can, however, replace INTEGER(LPVOID) with TYPE(C_PTR).

If you wish, we can switch to private conversation; my e-mail is jdujic AT uns.ac.rs.