[Mingw-users] Some questions on __imp_ prefix, and other linking problems

[俞晓磊]

Hello,
I'm a newbie in C/C++ and have encountered some problems when linking
against dlls. After some googling, I think I need some basic knowledge of
linking, object, impport, exort library ...:
1. In which circumstance will external functions be prefixed by __imp_ and
suffixed by @xxx?
2. Can I have some control over these prefixes and suffixes?
I found "extern" keyword removes the __imp_ prefix, but I just couldn't
remove @xxx suffix,
or I am just wrong
3. If __imp_ is a convention to indicate external functions imported from a
dll, how will @xxx help, and what does the number xxx mean?
I believe gcc does not know how linking will happen when compiling
source code,
thus @xxx suffixes have no use at all
I may solve my problem when I have some info on these questions, but I think
it proper to describe my situation:
I wrote some opengl es code and found it handy to just link them against
libEGL and libGLESv2 shipped with Firefox. But the linking fails because
objects expects __imp_* functions while functions in the dlls contains no
prefix

`pexport libEGL.dll` produces:
LIBRARY libEGL.dll
EXPORTS
eglBindAPI
eglBindTexImage
eglChooseConfig
eglCopyBuffers
...

`nm EGLExample.o` produces:
...
U ***@4
U ***@0
U ***@12

[John Brown]

Hello ÓáÏþÀÚ,

Post by 俞晓磊
1. In which circumstance will external functions be prefixed by __imp_

When the function follows the stdcall calling convention.

Post by 俞晓磊
2. Can I have some control over these prefixes and suffixes?
I found "extern" keyword removes the __imp_ prefix, but I just couldn't
or I am just wrong

The linker has a --kill-at flag (or something like that) that will remove the @n
from the function names. See the MinGW FAQ; specifically, the section about
DLLs. However, I think that this applies when *you* are building the DLL. I
do not know if this flag can be used to build

Post by 俞晓磊
3. If __imp_ is a convention to indicate external functions imported from a dll,
I believe gcc does not know how linking will happen when compiling source code,

I am inclined to agree with you that the name decoration (mangling) serves no
useful purpose. The number after the @ is the total number of bytes in the
paramater list, so int f(int x, long y) would become ***@12, assuming that an int
is 4 bytes, and a long is 8 bytes.

Post by 俞晓磊
I may solve my problem when I have some info on these questions, but I think
I wrote some opengl es code and found it handy to just link them against libEGL
and libGLESv2 shipped with Firefox. But the linking fails because objects expects
__imp_* functions while functions in the dlls contains no prefix
LIBRARY libEGL.dll
EXPORTS
eglBindAPI
eglBindTexImage
eglChooseConfig
eglCopyBuffers
...
...

What does `nm libEGL.a` say? Are you linking directly to the DLL or are you
using import libraries?

There may be an easier way, but you can create aliases in the .DEF file:
EXPORTS
eglBindAPI=***@x
eglBindTexImage=***@y

or something similar. Again, I think that the MinGW FAQ will help.

Regards,
Alias John Brown.

[俞晓磊]

Hello John
Thanks for your information.

Post by John Brown
What does `nm libEGL.a` say? Are you linking directly to the DLL or are you
using import libraries?

Yes, I am linking to libEGL.dll and libGLESv2.dll.

Post by John Brown
EXPORTS
or something similar. Again, I think that the MinGW FAQ will help.
<http://InboxLight.aspx?n=454371129#>

I followed MinGW faq and produced .a files from the dlls. Things seem to be
fine.
But I still cannot found any documentation on *_imp_* prefix. The faq does
mention __stdcall prefix, but it is for msvc.
Best Regards

[John Brown]

Hello ÓáÏþÀÚ

I followed MinGW faq and produced .a files from the dlls. Things seem to be fine.
But I still cannot found any documentation on *_imp_* prefix. The faq does
mention __stdcall prefix, but it is for msvc.

I gave you wrong / incomplete information. Using stdcall causes the @n to be
added to function names. __declspec(import), which tells the compiler that the
function is imported from a DLL, is what adds the __imp_ prefix.

See http://support.microsoft.com/kb/132044 for more information.

Regards,
Alias John Brown.

[Greg Chicares]

Post by John Brown
added to function names. __declspec(import), which tells the compiler that the
function is imported from a DLL, is what adds the __imp_ prefix.

I see __imp_ symbols in code that I've linked directly to a dll,
with no __declspec decorations used anywhere, so I guess direct
linking generates them, too.

Post by John Brown
See http://support.microsoft.com/kb/132044 for more information.

Also see:
http://blogs.msdn.com/b/oldnewthing/archive/2006/07/27/679634.aspx

[Earnie]

Post by 俞晓磊
I followed MinGW faq and produced .a files from the dlls. Things seem to be
fine.
But I still cannot found any documentation on *_imp_* prefix. The faq does
mention __stdcall prefix, but it is for msvc.

You don't need to create the .a, binutils will use the dlls directly to
get the import information. You just need to make sure that ld can find
the dll.

I suggest following leads via
http://www.google.com/search?q=binutils+__imp_ for how/what information
on the *_imp_* prefix.