[Top][All Lists]
[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?
- (no subject),
Пухальский Юрий Андреевич <=
- (no subject), Bobbie McNeill, 2005/03/16
- (no subject), sadfa, 2005/03/17
- (no subject), Mike Stump, 2005/03/28
- Re:, Mike Stump, 2005/03/28
- (no subject), Mike Stump, 2005/03/29