Brian Dessent wrote:
Jason Curl wrote:
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info
0:0:0 -o libtp.la -rpath /usr/local/lib version.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
Libtool won't build shared libraries on Win32/PE targets without
-no-undefined in *_LDFLAGS. The text of this warning message could
perhaps be clearer, because it's not telling you that you necessarily
have any undefined symbols, it's telling you that you didn't assure
libtool that you don't.
I guess what happens if I don't say this the build will fail. I've
turned it on and it looks good. I'll try and search more info later, but
while I'm at it:
- Why is it .dll.a and not .dll?
- How is versioning information embedded in the DLL, or is the basis of
the DLL hell?
lib -OUT:.libs/libtp.lib version.o
../libtool: line 5973: lib: command not found
I'm not sure why it's trying to use lib here, that seems wrong if you're
using gcc/binutils. Possibly a configure problem?
It was a configure problem. My shame! Trying to work around a Solaris 10
issue, where the "ld" is not found automatically I wrote an AC_PROG_LD.
Unfortunately this gets used instead of the original and I never noticed
if there were any conflicts. That's why it didn't matter if I used it or
not in my configure.ac script, I actually had to delete it first before
everything came back to normal.
Sorry for the noise. It looks like I'll have to read up a lot more about
shared library concepts in general to understand libtool better. Only
one more problem I know of to go!
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
