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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
