Some questions on __imp_ prefix, and other linking problems

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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 __imp__eglGetDisplay@4
         U __imp__eglGetError@0
         U __imp__eglInitialize@12



------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
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
|

Re: Some questions on __imp_ prefix, and other linking problems

John Brown
Hello 俞晓磊,

> 1. In which circumstance will external functions be prefixed by __imp_
> and suffixed by @xxx?

When the function follows the stdcall calling convention.

> 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

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

> 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 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 f@12, assuming that an int
is 4 bytes, and a long is 8 bytes.


> 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 __imp__eglGetDisplay@4
>        U __imp__eglGetError@0
>        U __imp__eglInitialize@12


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=eglBindAPI@x
eglBindTexImage=eglBindTexImage@y

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

Regards,
Alias John Brown.

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
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
|

Re: Some questions on __imp_ prefix, and other linking problems

俞晓磊
In reply to this post by 俞晓磊
Hello John
Thanks for your information.

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.

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

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

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

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
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
|

Re: Some questions on __imp_ prefix, and other linking problems

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.


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
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
|

Re: Some questions on __imp_ prefix, and other linking problems

Greg Chicares
On 2011-03-28 05:18Z, John Brown wrote:
>
> 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.

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.

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

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

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
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
|

Re: Some questions on __imp_ prefix, and other linking problems

Earnie Boyd
In reply to this post by 俞晓磊
俞晓磊 wrote:
> 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.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
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