libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: windows static archive, missing symbols


From: Duft Markus
Subject: RE: windows static archive, missing symbols
Date: Mon, 22 Jan 2007 07:57:48 +0100

Howard Chu <> wrote:
> Bob Rossi wrote:
>> Hi,
>> 
>> I've got a quick question hopefully. I'm building pcre on windows.
>> I've 
>> been able to build it into a dll and link against it with a small
>> program. However, when I build a static library, and link it with a
>> small program, I get the missing symbols error.
>> 
>> I know the symbols are in the library because nm tells me so,
>>   $ nm -g
>>   /home/bobbybrasko/download/pcre/pcre/install/lib/libpcre.a|grep
>> compile   libpcre_la-pcre_compile.o: 00005550 T _pcre_compile 
>> 
>> Here is the link line of the small program,
>>   $ gcc-4.1 -g -Wall -o test test.c
>> -L/home/bobbybrasko/download/pcre/pcre/install/lib \ 
>>     -lpcreposix -lpcre
>>   -I/home/bobbybrasko/download/pcre/pcre/install/include
>>   C:/WINDOWS/TEMP/ccgGAsIC.o(.text+0x2e): In function `main':
>>  
>>    
>> C:/msys/1.0/home/bobbybrasko/download/pcre/pcre/build/tmp/test.c:13:
>> undefined reference to `_imp__pcre_compile'                         
>> collect2: ld returned 1 exit status   
>> 
>> Does anyone understand why I'd be getting these errors? Are .def
>> files 
>> important for static windows libraries or only for dll's? Any advice?
>> 
> First of all, obviously "_imp__pcre_compile" is not the same as
> "_pcre_compile" so the error message is legitimate - the symbol that
> it's actually looking for is not there.
> 
> The next question is, why is it looking for an import symbol instead
> of using the real symbol. The answer to that must lie in your header
> files; they probably declare the function to be a DLL export, which
> causes the compiler to generate references to an import symbol. Have
> a look at your header files. Remove any DLL declspec's on any
> function declarations you find there; modern linkers don't need them.
> I.e., the GNU linker is 
> smart enough to use an import symbol in place of a reference to a real
> symbol. Apparently it won't do the opposite.
> 
> Unfortunately if a library exports variables as well, you need to
> preserve the export declspecs there. This means for any Windows
> library that you use, you have to know whether you will be using a
> static or a dynamic version, whenever compiling an app that uses the
> library. Very braindead, and there's no solution to that problem. The
> workaround is to never export variables from your libraries, only
> functions/accessor methods. 

Hi!

There is a solution to this problem, but for now it is only present in
interix-wgcc, which uses cl.exe and not gcc/ld. The solution is, to make
a wrapper generate symbols whenusing static libraries, to make the
linker think it is a shared library... Works perfectly ;o)

Cheers, Markus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]