[Top][All Lists]

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

Re: windows static archive, missing symbols

From: Howard Chu
Subject: Re: windows static archive, missing symbols
Date: Fri, 19 Jan 2007 18:30:19 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070113 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a

Bob Rossi wrote:

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.

 -- Howard Chu
 Chief Architect, Symas Corp.
 Director, Highland Sun
 OpenLDAP Core Team  

reply via email to

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