Trouble linking with particular libs
-
Hi. I'm having trouble linking with particular libs. I have an OGL ES app that needs functions in libGLES_CM.dll. I have two versions of this dll and the corrisponding libs. The first I got from the Khronos site. This version works. The second, I'm building from source. This version doesn't. The problem is unresolved externals. If I look at the lib files in Visual studio, the function names seem to be decorated differently. In the Khronos version, it looks like this... __imp__glTranslatex._glTranslatex In the version I build from source, it looks like this... __imp__glTranslatex@12._glTranslatex@12 What do I need to do to my app or visual studio to be able to link to the second version that I build from source? Thanks!
-
Hi. I'm having trouble linking with particular libs. I have an OGL ES app that needs functions in libGLES_CM.dll. I have two versions of this dll and the corrisponding libs. The first I got from the Khronos site. This version works. The second, I'm building from source. This version doesn't. The problem is unresolved externals. If I look at the lib files in Visual studio, the function names seem to be decorated differently. In the Khronos version, it looks like this... __imp__glTranslatex._glTranslatex In the version I build from source, it looks like this... __imp__glTranslatex@12._glTranslatex@12 What do I need to do to my app or visual studio to be able to link to the second version that I build from source? Thanks!
I'm not familiar with the particular libraries or DLLs are using, so I apologise if my comments below are obvious or not helpful. I think the @12 means your function is being compiled as a __stdcall function. If the function does not have a calling convention specified (e.g. __fastcall or __cdecl) or some equivalent macro (e.g. WINAPI) then your compile options may be selecting a different calling convention from the one intended. (Check for /Gz compile option and try using /Gr instead). I'd also check such things as your predefined macros (e.g. WIN32 _MSC_VER etc) and other -D options. If the code you are compiling is intended for multiple platforms things like calling conventions are likely to be very sensitive to this, because the code will be trying to cope with different compilers. Another possible cause of confusion is the method used to build the import library. You can get quite different results depending on whether you have a .DEF file or not, and whether you make use of the .EXP file or not. If you don't have a .DEF file, the linker will usually use your functions actual signature for the .LIB file, but if you have a .DEF file you may be able to remove the decoration. Personally I always use a .DEF file, and put NONAMES everywhere. It might be an idea to try to locate a makefile for the Khronos version.
-
I'm not familiar with the particular libraries or DLLs are using, so I apologise if my comments below are obvious or not helpful. I think the @12 means your function is being compiled as a __stdcall function. If the function does not have a calling convention specified (e.g. __fastcall or __cdecl) or some equivalent macro (e.g. WINAPI) then your compile options may be selecting a different calling convention from the one intended. (Check for /Gz compile option and try using /Gr instead). I'd also check such things as your predefined macros (e.g. WIN32 _MSC_VER etc) and other -D options. If the code you are compiling is intended for multiple platforms things like calling conventions are likely to be very sensitive to this, because the code will be trying to cope with different compilers. Another possible cause of confusion is the method used to build the import library. You can get quite different results depending on whether you have a .DEF file or not, and whether you make use of the .EXP file or not. If you don't have a .DEF file, the linker will usually use your functions actual signature for the .LIB file, but if you have a .DEF file you may be able to remove the decoration. Personally I always use a .DEF file, and put NONAMES everywhere. It might be an idea to try to locate a makefile for the Khronos version.