bug-libtool
[Top][All Lists]
Advanced

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

(no subject)


From: Пухальский Юрий Андреевич
Subject: (no subject)
Date: Wed, 9 Mar 2005 15:40:58 +0300

Hi there,
Good day!

Sorry for the late response.
Thank you for the response in question:)

> We see, that "-z blablaextract" options are being gathered adjacently, 
> and thus losing its meaning... And therefore in the resulting shared 
> library we don't get symbols from libbar unless they are being 
> referenced in libfoo (or probably in the symfile).

This looks like the compiler frontend reorders the options, not libtool. Is 
there an option we can pass to /opt/SUNWspro/bin/CC to keep it from reordering?
Yes, the compiler does. And I don't know of any such option... I've sent a 
question to the Sun forum, now am waiting for an answer. If this behaviour is 
intended, we could think of working around this. Eg. reordering the libraries 
in CC command line, and using -allextract option before libraries, that must be 
allextracted. But I hope it will be considered a bug by Sun:) 

I don't know what else we could do (but I know little about Solaris).
Btw, another issue I stepped on Solaris. Compiler 5.6 (Studio 10).

I use libtool for the following.
I make a small static library to be linked to the resulting shared. 
Unfortunately, this static library is being made only of non-PIC objects 
(although both PIC and non-PIC ones are compiled). Is it maybe possible to have 
both versions of intermediate static libraries, from PIC and non-PIC objects? 
Or should I use partial linking or any other means? 




reply via email to

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