Re: Libtool woes

[Jason Curl]

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!