libtool
[Top][All Lists]
Advanced

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

Re: no-undefined, solaris sun studio and pain


From: Monty Taylor
Subject: Re: no-undefined, solaris sun studio and pain
Date: Thu, 24 Dec 2009 10:09:51 -0800
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Bob Friesenhahn wrote:
> On Wed, 23 Dec 2009, Monty Taylor wrote:
>>
>> Thing is - libprotobuf.so hasn't been installed in /usr/local/lib/amd64
>> yet, so the -lprotobuf seems to trigger the unknown symbols above.
>>
>> If I remove -no-undefined from the LDFLAGS or I manually edit the above
>> line to do:
>>
>> CC -G -zdefs -hlibprotoc.so.6 -o .libs/libprotoc.so.6.0.0   <various .o
>> files snipped>  -R/usr/local/lib/amd64 -L/usr/local/lib/amd64
>> .libs/libprotobuf.so -library=stlport4 -library=Crun -lpthread -lz -lc
>> -template=no%extdef -mt -m64   -mt
>>
>> It works. Of course, I know the above editing is wrong, because it
>> really wants to be linked with -lprotobuf. Am I just SOL in terms of
>> being able to use -no-undefined in this case? It would be nice to get
>> that error on the compile-for-tree stage but not have it apply to the
>> relink for install phase.
> 
> I believe that the problem is with the order that the libraries are
> being installed.  Unfortunately, Automake does not fully understand
> library dependencies so it is necessary to list the libraries in the
> correct dependency order for installation since programs and libraries
> may be re-linked at install time.  Consider that if an old version of
> libprotobuf.so had already been installed, that this old version would
> be accidentally used rather than the new version you are installing. If
> you have two libraries which depend on each other's symbols, then the
> libraries will need to be redesigned.

Ok... I checked that, and we do have the deps set correctly. In fact, it
_is_ doing the right thing and installing libprotobuf first, and then
attempting to relink libprotoc. (whee!)

Here's where it gets... weird?

The following doesn't work:

CC -G -zdefs -hlibprotoc.so.6 -o .libs/libprotoc.so.6.0.0
-R/usr/local/protobuf230/lib/amd64 -L/usr/local/lib/amd64
-L/usr/local/protobuf230/lib/amd64 -lprotobuf -library=stlport4
-library=Crun -lpthread -lz -lc   -mt -m64

but this does:

CC -G -zdefs -hlibprotoc.so.6 -o .libs/libprotoc.so.6.0.0
-R/usr/local/protobuf230/lib/amd64 -L/usr/local/protobuf230/lib/amd64
-lprotobuf -library=stlport4 -library=Crun -lpthread -lz -lc   -mt -m64

So - a) I've managed to get an extra -L/usr/local/lib/amd64 injected in
there and b) it confuses the crap out of the linker. (/me doesn't see
why additional -L flags should cause so much trouble... but at least
I've got somewhere to look now...)

Thanks!
Monty




reply via email to

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