undefined reference to _imp__*

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

undefined reference to _imp__*

Cervinka, Mitch
I am trying to build an old Fortran program with GFortran (ver 5.3.0) on Windows 10 using MinGW.  It links in a DLL and calls various functions in that DLL.  When I build the program, I am seeing numerous errors like "undefined reference to '_imp__*', where * is the actual name of the function.  I have used Dependency Walker to view the names of the entry points in the DLL, and none of them begins with _imp__.  How do I tell the GFortran compiler to not expect the functions to begin with _imp__ ?


Here's a sample of the one of the function definitions in the INTERFACE block ...

         FUNCTION STMVPT (P,T) bind(C, name="STMVPT97")
            use iso_c_binding, only: c_double
!GCC$       attributes stdcall, dllimport     ::  STMVPT
            real    (kind=c_double)           ::  STMVPT
            real    (kind=c_double), value    ::  P
            real    (kind=c_double), value    ::  T
         END FUNCTION STMVPT

When I build my project, I am seeing the following message ...

       :  undefined reference to '_imp__STMVPT97@16'


Dependency Walker shows the following 2 names for this function's entry point ...

       STMVPT97
       _stmvpt97@16

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Eli Zaretskii
> From: "Cervinka, Mitch" <[hidden email]>
> Date: Fri, 13 Jan 2017 19:19:29 +0000
>
> I am trying to build an old Fortran program with GFortran (ver 5.3.0) on Windows 10 using MinGW.  It links in a DLL and calls various functions in that DLL.  When I build the program, I am seeing numerous errors like "undefined reference to '_imp__*', where * is the actual name of the function.  I have used Dependency Walker to view the names of the entry points in the DLL, and none of them begins with _imp__.  How do I tell the GFortran compiler to not expect the functions to begin with _imp__ ?

I think you didn't link against the import library of that DLL.
That's where those _imp__* symbols live.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
Are you saying, then, that the DEF file from which the import library is created should provide an alias for each symbol in the DLL?

My present DEF file has entries like these ...

EXPORTS
    symbol1 @1 DATA
    symbol2 @2
    symbol3 @3

Should it have this instead?  ...

EXPORTS
    _imp__ symbol1@16=symbol1 @1 DATA
    _imp__ symbol2@16=symbol2 @2
    _imp__ symbol3@16=symbol3 @3


Thank you for your assistance, Eli.



-----Original Message-----
From: Eli Zaretskii [mailto:[hidden email]]
Sent: Friday, January 13, 2017 2:39 PM
To: MinGW Users List <[hidden email]>
Subject: Re: [Mingw-users] undefined reference to _imp__*

> From: "Cervinka, Mitch" <[hidden email]>
> Date: Fri, 13 Jan 2017 19:19:29 +0000
>
> I am trying to build an old Fortran program with GFortran (ver 5.3.0) on Windows 10 using MinGW.  It links in a DLL and calls various functions in that DLL.  When I build the program, I am seeing numerous errors like "undefined reference to '_imp__*', where * is the actual name of the function.  I have used Dependency Walker to view the names of the entry points in the DLL, and none of them begins with _imp__.  How do I tell the GFortran compiler to not expect the functions to begin with _imp__ ?

I think you didn't link against the import library of that DLL.
That's where those _imp__* symbols live.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi _______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Eli Zaretskii
> From: "Cervinka, Mitch" <[hidden email]>
> Date: Tue, 17 Jan 2017 15:39:04 +0000
>
> Are you saying, then, that the DEF file from which the import library is created should provide an alias for each symbol in the DLL?

No, I don't think so.

If you run "nm -A" on the import library, which symbols do you see
there?  You should see __imp__* symbols marked as "I" and the symbols
from your DEF file marked as "T".  You can see an example of that if
you run "nm -A" on one of the lib*.a import libraries that come with
MinGW's w32api package.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
Okay.  Yes, I'm seeing the imp prefixes in the lib file.
However, the underscores are wrong.

If I build the import library with DLLTOOL using the --no-leading-underscore option, and then use "nm -A" to examine the file, I see names like ...

          __imp_SYMBOL1            (i.e. 2 underscores before imp and 1 before the name)

If I build it without that option, the names look like this ...

          __imp__SYMBOL1            (i.e. 2 underscores before imp and 2 before the name)

However, the linker is looking for names like ...

          _imp__SYMBOL1            (i.e. 1 underscore before imp and two before the name)


In other words, DLLTOOL seems to always prefix imp with two underscores, but the linker is looking for names where imp is prefixed by only a single underscore.

I tried linking again, but am still seeing the "undefined reference" messages, due to the extra underscore.

Any insights on how to handle this?



-----Original Message-----
From: Eli Zaretskii [mailto:[hidden email]]
Sent: Tuesday, January 17, 2017 1:40 PM
To: Cervinka, Mitch <[hidden email]>
Cc: [hidden email]
Subject: Re: [Mingw-users] undefined reference to _imp__*

> From: "Cervinka, Mitch" <[hidden email]>
> Date: Tue, 17 Jan 2017 15:39:04 +0000
>
> Are you saying, then, that the DEF file from which the import library is created should provide an alias for each symbol in the DLL?

No, I don't think so.

If you run "nm -A" on the import library, which symbols do you see there?  You should see __imp__* symbols marked as "I" and the symbols from your DEF file marked as "T".  You can see an example of that if you run "nm -A" on one of the lib*.a import libraries that come with MinGW's w32api package.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Earnie Boyd
On 1/17/2017 5:25 PM, Cervinka, Mitch wrote:

> Okay.  Yes, I'm seeing the imp prefixes in the lib file.
> However, the underscores are wrong.
>
> If I build the import library with DLLTOOL using the --no-leading-underscore option, and then use "nm -A" to examine the file, I see names like ...
>
>           __imp_SYMBOL1            (i.e. 2 underscores before imp and 1 before the name)
>
> If I build it without that option, the names look like this ...
>
>           __imp__SYMBOL1            (i.e. 2 underscores before imp and 2 before the name)
>
> However, the linker is looking for names like ...
>
>           _imp__SYMBOL1            (i.e. 1 underscore before imp and two before the name)
>
>
> In other words, DLLTOOL seems to always prefix imp with two underscores, but the linker is looking for names where imp is prefixed by only a single underscore.
>

Why are you using dlltool; it is no longer supported.

> I tried linking again, but am still seeing the "undefined reference" messages, due to the extra underscore.
>
> Any insights on how to handle this?
>

You don't need an import library.  You can link directly with the dll.

E. G.

If you have foo.dll in /PATH/TO/FOO then you can use

gcc -o foo.exe foo.o -L /PATH/TO/FOO -l foo

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Eli Zaretskii
In reply to this post by Cervinka, Mitch
> From: "Cervinka, Mitch" <[hidden email]>
> CC: "[hidden email]" <[hidden email]>
> Date: Tue, 17 Jan 2017 22:25:35 +0000
>
> Okay.  Yes, I'm seeing the imp prefixes in the lib file.
> However, the underscores are wrong.
>
> If I build the import library with DLLTOOL using the --no-leading-underscore option, and then use "nm -A" to examine the file, I see names like ...
>
>           __imp_SYMBOL1            (i.e. 2 underscores before imp and 1 before the name)
>
> If I build it without that option, the names look like this ...
>
>           __imp__SYMBOL1            (i.e. 2 underscores before imp and 2 before the name)
>
> However, the linker is looking for names like ...
>
>           _imp__SYMBOL1            (i.e. 1 underscore before imp and two before the name)

No, the linker should look for __imp__SYMBOL1.  That's what I see in
the MinGW import libraries, which definitely work.  Are you sure the
linker scans your import library?  Adding -v to the link command line
should show that.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
In reply to this post by Earnie Boyd
Hi Earnie,

I am new at MinGW and was not aware that DLLTOOL is no longer supported.

I had originally tried linking directly without the import library, but was getting "undefined reference" messages because the MinGW linker was expecting the prefix "_imp__" in front of all the imported symbol names, but the symbols in the DLL do not have this prefix.

The DLL exports its symbols using the STDCALL convention, so I assume I need to import them using STDCALL.  I wasn't seeing these linker errors when I tried to import using CDECL, but I was getting exceptions when I tried to run the code.  I don't believe it is valid to import symbols using CDECL if the DLL was exported with STDCALL, is it?

I do not have the luxury of rebuilding the DLL I am trying to import, so I am stuck with using STDCALL.  I believe life would be much easier if we were using CDECL, but that is not an option for me.




-----Original Message-----
From: Earnie [mailto:[hidden email]]
Sent: Wednesday, January 18, 2017 9:31 AM
To: [hidden email]
Subject: Re: [Mingw-users] undefined reference to _imp__*

On 1/17/2017 5:25 PM, Cervinka, Mitch wrote:

> Okay.  Yes, I'm seeing the imp prefixes in the lib file.
> However, the underscores are wrong.
>
> If I build the import library with DLLTOOL using the --no-leading-underscore option, and then use "nm -A" to examine the file, I see names like ...
>
>           __imp_SYMBOL1            (i.e. 2 underscores before imp and 1 before the name)
>
> If I build it without that option, the names look like this ...
>
>           __imp__SYMBOL1            (i.e. 2 underscores before imp and 2 before the name)
>
> However, the linker is looking for names like ...
>
>           _imp__SYMBOL1            (i.e. 1 underscore before imp and two before the name)
>
>
> In other words, DLLTOOL seems to always prefix imp with two underscores, but the linker is looking for names where imp is prefixed by only a single underscore.
>

Why are you using dlltool; it is no longer supported.

> I tried linking again, but am still seeing the "undefined reference" messages, due to the extra underscore.
>
> Any insights on how to handle this?
>

You don't need an import library.  You can link directly with the dll.

E. G.

If you have foo.dll in /PATH/TO/FOO then you can use

gcc -o foo.exe foo.o -L /PATH/TO/FOO -l foo

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
In reply to this post by Eli Zaretskii
Hi Eli,

I'm fairly sure it's finding the import library.  I was seeing different errors earlier when it could not find the library.

I tried adding the -v link switch, as you suggested, but I don't see anything in the output that tells me if it's actually reading the import library.

For what it's worth, I using the Eclipse(Mars version) IDE to build the code using the MinGW Fortran compiler and linker.



-----Original Message-----
From: Eli Zaretskii [mailto:[hidden email]]
Sent: Wednesday, January 18, 2017 10:21 AM
To: Cervinka, Mitch <[hidden email]>
Cc: [hidden email]
Subject: Re: [Mingw-users] undefined reference to _imp__*

> From: "Cervinka, Mitch" <[hidden email]>
> CC: "[hidden email]"
> <[hidden email]>
> Date: Tue, 17 Jan 2017 22:25:35 +0000
>
> Okay.  Yes, I'm seeing the imp prefixes in the lib file.
> However, the underscores are wrong.
>
> If I build the import library with DLLTOOL using the --no-leading-underscore option, and then use "nm -A" to examine the file, I see names like ...
>
>           __imp_SYMBOL1            (i.e. 2 underscores before imp and 1 before the name)
>
> If I build it without that option, the names look like this ...
>
>           __imp__SYMBOL1            (i.e. 2 underscores before imp and 2 before the name)
>
> However, the linker is looking for names like ...
>
>           _imp__SYMBOL1            (i.e. 1 underscore before imp and two before the name)

No, the linker should look for __imp__SYMBOL1.  That's what I see in the MinGW import libraries, which definitely work.  Are you sure the linker scans your import library?  Adding -v to the link command line should show that.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Keith Marshall-3
In reply to this post by Cervinka, Mitch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18/01/17 20:32, Cervinka, Mitch wrote:
> I am new at MinGW and was not aware that DLLTOOL is no longer
> supported.

You are reading too much into Earnie's statement; often, you may
not need an import library, since current versions of the linker support direct linking to DLLs, but dlltool _is_ still supported;
indeed, we still use it when building mingwrt and w32api.

> I had originally tried linking directly without the import library,
> but was getting "undefined reference" messages because the MinGW
> linker was expecting the prefix "_imp__" in front of all the imported
> symbol names, but the symbols in the DLL do not have this prefix.

Yes, they do ... implicitly; you just will not normally see them
on examination of the DLL itself, but you can see them in any
import library you generate from your DLL.

> The DLL exports its symbols using the STDCALL convention, so I assume
> I need to import them using STDCALL.  I wasn't seeing these linker
> errors when I tried to import using CDECL, but I was getting
> exceptions when I tried to run the code.  I don't believe it is valid
> to import symbols using CDECL if the DLL was exported with STDCALL,
> is it?

No, it isn't.  STDCALL pops arguments off the stack _before_ the
function returns; CDECL leaves the caller to pop them _after_ the
function returns.  Specifying this inappropriately trashes the
stack, and likely will induce crashes.

> I do not have the luxury of rebuilding the DLL I am trying to import,
> so I am stuck with using STDCALL.  I believe life would be much
> easier if we were using CDECL, but that is not an option for me.

STDCALL functions normally append an @N decoration to the symbol
name, (with no intervening space ... the @N references in your DEF
file are entirely different ordinal references), but some DLLs do
not export them in this fully qualified form.  If you have one of
these, you may need to build an import library in which you
specify both the qualified and unqualified forms; (the N in the
required "Symbol@N" references represents the number of bytes in
the argument list, which the associated function will pop off the
stack when it returns).

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYf+cZAAoJEMCtNsY0flo/Em4QAKsV4Huc/SiuIXpbmlylfTgd
WW5xinK/boUbXyyDylzUhw1CxO17XPDGMg5YcfyOsLL99cCzkowtI/ORLxMaH3/X
1nzHGa2rQL67ffH96McGeAhHTI4dmNdtOUBrAvcCf90Xf1OaUS0zMg9M3PILWm4Q
nTzm6osO6Mmb/6jzjDTcpHstdyS5FfPeSET1Zpnv4BuF/jiDVhtWcJ4SsJDpfPwK
2LRUyRnIJca8fkQY8bv25I0a4P6C5+M1weplTjlQaeJ3RP70u5F3dcd8bom4AUWb
79msG1z+STdqAtj7H5O9K8IfrVg2JKdo52zvJf4mP0zLQ8R8lSIopPhfUTt+J7Ha
3U3HpK7gCMoQbOrPSrZ3IO5HSebElqJb028KAlzqaHQyyQ9LLriQhLSJe87+y7km
jAolYofzi2fCnauuA8aIl4BVYt13VEWPZL8nCPyKXjFyBa9JDr4TqvRiwCYjcbk9
SSkJs5eULi3kAB6DE1Hcmylsb4Rj+hNpjcuLqrIsBuic7YV4Ur7d7i1MJLBtbT3d
d8Nn0JnSXkOTN2Y6w0KMvdG0f1eXVCw3pz0gsQP+aDL0g9Y3gGCDdCuJNVjvrLOK
UntlyMY+IfiyhBkb3lFnwMAjRSxpjGc4YN5YNQGwsXvtv1zICysrykBZ2w8LUPws
aY0iK8/JRsT/1oRkf1ic
=3qxg
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
In reply to this post by Eli Zaretskii
More confirmation that it's finding the import library ...

I originally just had the name of the library file, without the leading "lib" or the file extension ".a".
Then, in Eclipse, I tried adding, to Project/Properties/"Fortran Build"/"Settings"/"GNU Fortran Linker"/"Libraries (-l)", the following items ...

   myexplib
   myexplib.a
   libmyexplib
   libmyexplib.a

This time, when I built my code, the linker complained about the last 3 files, but did not complain about the first one, and it did not list any of the "undefined reference" messages.

... cannot find -lmyexplib.a
... cannot find -llibmyexplib
... cannot find -llibmyexplib.a

I am not seeing any "cannot find" messages when myexplib is the only item in the list.  Instead, I'm seeing the "undefined reference" messages.

-- -- --

I found the following comment on another website (http://mirrors.zoreil.com/webclub.kcom.ne.jp/ma/colinp/win32/dll/use.html) ...

"Older versions of dlltool used __imp_ as the prefix instead of _imp__. The new prefix is more compatible with Microsoft, and dlltool includes both for backward compatibility, but these type of changes show just how dangerous such a kludge can be."

I checked the version of dlltool I am using.  It is

   GNU dlltool (GNU Binutils) 2.25.1
   Copyright (C) 2014 Free Software Foundation, Inc.

Is there a newer version of DLLTOOL I should be using?  Or, is there a command-line switch that controls how many leading underscores are generated (i.e. before imp_) ?




-----Original Message-----
From: Cervinka, Mitch
Sent: Wednesday, January 18, 2017 2:40 PM
To: Eli Zaretskii <[hidden email]>
Cc: [hidden email]
Subject: RE: [Mingw-users] undefined reference to _imp__*

Hi Eli,

I'm fairly sure it's finding the import library.  I was seeing different errors earlier when it could not find the library.

I tried adding the -v link switch, as you suggested, but I don't see anything in the output that tells me if it's actually reading the import library.

For what it's worth, I using the Eclipse(Mars version) IDE to build the code using the MinGW Fortran compiler and linker.



-----Original Message-----
From: Eli Zaretskii [mailto:[hidden email]]
Sent: Wednesday, January 18, 2017 10:21 AM
To: Cervinka, Mitch <[hidden email]>
Cc: [hidden email]
Subject: Re: [Mingw-users] undefined reference to _imp__*

> From: "Cervinka, Mitch" <[hidden email]>
> CC: "[hidden email]"
> <[hidden email]>
> Date: Tue, 17 Jan 2017 22:25:35 +0000
>
> Okay.  Yes, I'm seeing the imp prefixes in the lib file.
> However, the underscores are wrong.
>
> If I build the import library with DLLTOOL using the --no-leading-underscore option, and then use "nm -A" to examine the file, I see names like ...
>
>           __imp_SYMBOL1            (i.e. 2 underscores before imp and 1 before the name)
>
> If I build it without that option, the names look like this ...
>
>           __imp__SYMBOL1            (i.e. 2 underscores before imp and 2 before the name)
>
> However, the linker is looking for names like ...
>
>           _imp__SYMBOL1            (i.e. 1 underscore before imp and two before the name)

No, the linker should look for __imp__SYMBOL1.  That's what I see in the MinGW import libraries, which definitely work.  Are you sure the linker scans your import library?  Adding -v to the link command line should show that.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
In reply to this post by Eli Zaretskii
It appears to be working now.  I am able to successfully build my Fortran project.  I am not seeing the "undefined reference" messages any more.

I think the problem may have been in the LIBRARY section of my DEF file.  I don't think I had the correct DLL name listed there.  After fixing that problem and rebuilding the implib.a file with DLLTOOL, I rebuilt my project and did not see the errors.

For what it's worth, I looked at the imported library using NM -A, and am still seeing 2 underscores in front of the "imp" prefixes, but the linker seems to be happy with that now.

Thank you for your help, Eli.




-----Original Message-----
From: Cervinka, Mitch
Sent: Wednesday, January 18, 2017 4:37 PM
To: Eli Zaretskii <[hidden email]>
Cc: [hidden email]
Subject: RE: [Mingw-users] undefined reference to _imp__*

More confirmation that it's finding the import library ...

I originally just had the name of the library file, without the leading "lib" or the file extension ".a".
Then, in Eclipse, I tried adding, to Project/Properties/"Fortran Build"/"Settings"/"GNU Fortran Linker"/"Libraries (-l)", the following items ...

   myexplib
   myexplib.a
   libmyexplib
   libmyexplib.a

This time, when I built my code, the linker complained about the last 3 files, but did not complain about the first one, and it did not list any of the "undefined reference" messages.

... cannot find -lmyexplib.a
... cannot find -llibmyexplib
... cannot find -llibmyexplib.a

I am not seeing any "cannot find" messages when myexplib is the only item in the list.  Instead, I'm seeing the "undefined reference" messages.

-- -- --

I found the following comment on another website (http://mirrors.zoreil.com/webclub.kcom.ne.jp/ma/colinp/win32/dll/use.html) ...

"Older versions of dlltool used __imp_ as the prefix instead of _imp__. The new prefix is more compatible with Microsoft, and dlltool includes both for backward compatibility, but these type of changes show just how dangerous such a kludge can be."

I checked the version of dlltool I am using.  It is

   GNU dlltool (GNU Binutils) 2.25.1
   Copyright (C) 2014 Free Software Foundation, Inc.

Is there a newer version of DLLTOOL I should be using?  Or, is there a command-line switch that controls how many leading underscores are generated (i.e. before imp_) ?




-----Original Message-----
From: Cervinka, Mitch
Sent: Wednesday, January 18, 2017 2:40 PM
To: Eli Zaretskii <[hidden email]>
Cc: [hidden email]
Subject: RE: [Mingw-users] undefined reference to _imp__*

Hi Eli,

I'm fairly sure it's finding the import library.  I was seeing different errors earlier when it could not find the library.

I tried adding the -v link switch, as you suggested, but I don't see anything in the output that tells me if it's actually reading the import library.

For what it's worth, I using the Eclipse(Mars version) IDE to build the code using the MinGW Fortran compiler and linker.



-----Original Message-----
From: Eli Zaretskii [mailto:[hidden email]]
Sent: Wednesday, January 18, 2017 10:21 AM
To: Cervinka, Mitch <[hidden email]>
Cc: [hidden email]
Subject: Re: [Mingw-users] undefined reference to _imp__*

> From: "Cervinka, Mitch" <[hidden email]>
> CC: "[hidden email]"
> <[hidden email]>
> Date: Tue, 17 Jan 2017 22:25:35 +0000
>
> Okay.  Yes, I'm seeing the imp prefixes in the lib file.
> However, the underscores are wrong.
>
> If I build the import library with DLLTOOL using the --no-leading-underscore option, and then use "nm -A" to examine the file, I see names like ...
>
>           __imp_SYMBOL1            (i.e. 2 underscores before imp and 1 before the name)
>
> If I build it without that option, the names look like this ...
>
>           __imp__SYMBOL1            (i.e. 2 underscores before imp and 2 before the name)
>
> However, the linker is looking for names like ...
>
>           _imp__SYMBOL1            (i.e. 1 underscore before imp and two before the name)

No, the linker should look for __imp__SYMBOL1.  That's what I see in the MinGW import libraries, which definitely work.  Are you sure the linker scans your import library?  Adding -v to the link command line should show that.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Earnie Boyd
On 1/19/2017 12:27 PM, Cervinka, Mitch wrote:
>
> For what it's worth, I looked at the imported library using NM -A, and am still seeing 2 underscores in front of the "imp" prefixes, but the linker seems to be happy with that now.
>

Have a look at

$ nm --help | grep demangle

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
Thanks for your help Earnie.


-----Original Message-----
From: Earnie [mailto:[hidden email]]
Sent: Thursday, January 19, 2017 4:09 PM
To: [hidden email]
Subject: Re: [Mingw-users] undefined reference to _imp__*

On 1/19/2017 12:27 PM, Cervinka, Mitch wrote:
>
> For what it's worth, I looked at the imported library using NM -A, and am still seeing 2 underscores in front of the "imp" prefixes, but the linker seems to be happy with that now.
>

Have a look at

$ nm --help | grep demangle

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: undefined reference to _imp__*

Cervinka, Mitch
In reply to this post by Keith Marshall-3
Thank you, Keith.  It's good to know that DLLTOOL is still supported.  I didn't use it initially, but when I started encountering problems trying to link the DLL directly, I searched and found some posts that suggested using DLLTOOL and a DEF file to create an import library.  

The rest of your message helps to confirm and clarify various things I had read about linking DLL's.  

I really appreciate your help!


-----Original Message-----
From: Keith Marshall [mailto:[hidden email]]
Sent: Wednesday, January 18, 2017 4:07 PM
To: [hidden email]
Subject: Re: [Mingw-users] undefined reference to _imp__*

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18/01/17 20:32, Cervinka, Mitch wrote:
> I am new at MinGW and was not aware that DLLTOOL is no longer
> supported.

You are reading too much into Earnie's statement; often, you may not need an import library, since current versions of the linker support direct linking to DLLs, but dlltool _is_ still supported; indeed, we still use it when building mingwrt and w32api.

> I had originally tried linking directly without the import library,
> but was getting "undefined reference" messages because the MinGW
> linker was expecting the prefix "_imp__" in front of all the imported
> symbol names, but the symbols in the DLL do not have this prefix.

Yes, they do ... implicitly; you just will not normally see them on examination of the DLL itself, but you can see them in any import library you generate from your DLL.

> The DLL exports its symbols using the STDCALL convention, so I assume
> I need to import them using STDCALL.  I wasn't seeing these linker
> errors when I tried to import using CDECL, but I was getting
> exceptions when I tried to run the code.  I don't believe it is valid
> to import symbols using CDECL if the DLL was exported with STDCALL, is
> it?

No, it isn't.  STDCALL pops arguments off the stack _before_ the function returns; CDECL leaves the caller to pop them _after_ the function returns.  Specifying this inappropriately trashes the stack, and likely will induce crashes.

> I do not have the luxury of rebuilding the DLL I am trying to import,
> so I am stuck with using STDCALL.  I believe life would be much easier
> if we were using CDECL, but that is not an option for me.

STDCALL functions normally append an @N decoration to the symbol name, (with no intervening space ... the @N references in your DEF file are entirely different ordinal references), but some DLLs do not export them in this fully qualified form.  If you have one of these, you may need to build an import library in which you specify both the qualified and unqualified forms; (the N in the required "Symbol@N" references represents the number of bytes in the argument list, which the associated function will pop off the stack when it returns).

- --
Regards,
Keith.

Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYf+cZAAoJEMCtNsY0flo/Em4QAKsV4Huc/SiuIXpbmlylfTgd
WW5xinK/boUbXyyDylzUhw1CxO17XPDGMg5YcfyOsLL99cCzkowtI/ORLxMaH3/X
1nzHGa2rQL67ffH96McGeAhHTI4dmNdtOUBrAvcCf90Xf1OaUS0zMg9M3PILWm4Q
nTzm6osO6Mmb/6jzjDTcpHstdyS5FfPeSET1Zpnv4BuF/jiDVhtWcJ4SsJDpfPwK
2LRUyRnIJca8fkQY8bv25I0a4P6C5+M1weplTjlQaeJ3RP70u5F3dcd8bom4AUWb
79msG1z+STdqAtj7H5O9K8IfrVg2JKdo52zvJf4mP0zLQ8R8lSIopPhfUTt+J7Ha
3U3HpK7gCMoQbOrPSrZ3IO5HSebElqJb028KAlzqaHQyyQ9LLriQhLSJe87+y7km
jAolYofzi2fCnauuA8aIl4BVYt13VEWPZL8nCPyKXjFyBa9JDr4TqvRiwCYjcbk9
SSkJs5eULi3kAB6DE1Hcmylsb4Rj+hNpjcuLqrIsBuic7YV4Ur7d7i1MJLBtbT3d
d8Nn0JnSXkOTN2Y6w0KMvdG0f1eXVCw3pz0gsQP+aDL0g9Y3gGCDdCuJNVjvrLOK
UntlyMY+IfiyhBkb3lFnwMAjRSxpjGc4YN5YNQGwsXvtv1zICysrykBZ2w8LUPws
aY0iK8/JRsT/1oRkf1ic
=3qxg
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Loading...