Re: pthreads in libtool'd shared library...

[Ralf Wildenhues]

* Chris Bowlby wrote on Mon, Nov 01, 2004 at 05:37:33PM CET:
> At 02:44 PM 10/31/2004, Ralf Wildenhues wrote:
> 
> >Try adding -no-undefined.  Should fail at library link time then.
> 
> This had no effect on the compiler, it still managed to compile with out 
> issue.

This seems to be a separate issue.  I'm not looking at that now.

> >Did you check that the `-pthread' option is really passed to the
> >compiler?  I don't have FreeBSD available to test (and no experience
> >with it), but online docs suggest it to be sufficient.
> 
> The -pthread parameter was being passed to the compiler:
> 
> /bin/bash ../../../libtool --mode=link g++  -g -O2   -L/usr/local/lib 
> -L/usr/lib -L/usr/compat/linux/lib -o libtest.la -rpath 
> /usr/local/data_cop/lib -module -Wsymbolic -pthread -no-undefined 
> test.lo  -lc_r -lcrypt -lpq -lcipher

> g++ -shared -nostdlib /usr/lib/crti.o 
> /usr/lib/crtbeginS.o  .libs/test.o  -L/usr/local/lib -L/usr/lib 
> -L/usr/compat/linux/lib -pthread -lcrypt -lpq -lcipher -lstdc++ -lm -lgcc 
> /usr/lib/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,libtest.so.0 -o 
> .libs/libtest.so.0

*snip*
> 
> >More random thoughts: try putting -pthread as very last thing on the
> >  libtool --mode=links -o libtest.la ...
> >cmdline.  Try the g++ link line (which libtool generates) by hand
> >and try to see what's necessary to fix it.
> 
> Changing the location of where -pthread was, did not help either. But, 
> having said that I added -lc_r to the list of parameters and it solved the 
> problem, but that only worked when I added it to the raw g++.... command. 
> It still seems that libtool is auto-dropping the -lc_r (Which we can see in 
> the list of parameters to be added to the command line to g++).... 
> preventing it from compiling properly. Even adding it to the LDFLAGS part 
> for the sake of testing, libtool stripped it out:

Yes.  I know it's doing this.  There is a reason for this as well, I
think, has to do with multiple instances of the same library being
pulled in in some occasions.

> /bin/bash ../../../libtool --mode=link g++  -g -O2   -L/usr/local/lib 
> -L/usr/lib -L/usr/compat/linux/lib -o libtest.la -rpath 
> /usr/local/data_cop/lib -module -Wsymbolic -pthread -no-undefined 
> test.lo  -lc_r -lcrypt -lpq -lcipher
> 
> This is the call libtool makes, as we can see -lc_r is part of the 
> parameter list here, but:
> 
> g++ -shared -nostdlib /usr/lib/crti.o 
> /usr/lib/crtbeginS.o  .libs/test.o  -L/usr/local/lib -L/usr/lib 
> -L/usr/compat/linux/lib -pthread -lcrypt -lpq -lcipher -lstdc++ -lm -lgcc 
> /usr/lib/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,libtest.so.0 -o 
> .libs/libtest.so.0
> 
> g++ never actually sees it.

ACK.


> >BTW, -Wsymbolic is not mentioned in the online docs.  Is that the same
> >as -Bsymbolic?
> 
> -B is a path related parameter, -W was mentioned on the dlopen related 
> pages so that when I link in my .so library, it already know's about 
> symbols in the executable, that might be global. This is only a temporary 
> solution until I can clean any of those ones out, and really just to help 
> me get the application written faster. Once I've got it written, I'll be 
> doing a code review that will clean that requirement out.

Ok, I know a workaround:
Add -pthread to the LDFLAGS for the executable you eventually create
(either progname_LDFLAGS or AM_LDFLAGS in that directory).


I'm attaching a test case for the other developers.  This fails on Linux
as well, is unfortunately not very portable yet (and would most probably
need acx_pthread.m4 or some adaptation of that).  Help is quite welcome,
maybe someone wants to turn it into a testsuite test?

I know too little about the problem to be able to suggest a solution.
For a full solution I guess it's necessary to add more information in
the .la file..

> >> #libtest_la_LDFLAGS = -version-info
> >> $(ABI_CURRENT):$(ABI_REVISION):$(ABI_AGE)
> >No need to remove the version-info.
> 
> Actually, I got an error when trying to use this line:
> libtool: link: CURRENT `' is not a nonnegative integer
> libtool: link: `::' is not valid version information
> *** Error code 1
> 
> and I had not had the chance to look into that yet, was planning on doing 
> that later, but if you can suggest a fix that would be great..

Looks like the variables ABI_CURRENT, ABI_REVISION and ABI_AGE are just
not set.  This is a separate issue.

Regards,
Ralf

pth_example.tar.gz
Description: GNU Zip compressed data