On Sun, 27 Nov 2005, Ralf Wildenhues wrote:
I hoped you would not say that.. ;-)
:). It's a bad header. It's described slightly differently by DJB and
an old DRUMS draft. Of the MUAs which interpret it, their actions
seems to differ. Those MUAs should stop supporting it really. Anyway,
a matter for another list (or private mail ;) ).
As in
-DPACKAGE_STRING=\"foo\ 0.1\"
for example? Granted, I don't know of so many linker flags which need
this.
Ouch, that's fairly nasty. If someone wants to do this, it'd be
easier to do:
#ifdef WANT_SPECIAL_FOO
#define PACKAGE_STRING "foo 0.1"
#else /* WANT_NEW_FOO */
#ifdef WANT_FOO
#define PACKAGE_STRING "foo 0.2"
#endif /* WANT_FOO */
#endif /* WANT_NEW_FOO */
And avoid the quoted define passed as -D argument.
The Wc method won't work for all flags though, I think. (And is a bit
tedious too).
Which? Please show.
Well, the Sun One Studio (SOS) cc man page contains the following
warning:
(1) Note: You cannot use -Wd to pass the cc options
listed in this man page to the C compiler.
So actually, I'm wrong, Wc would work - just would be quite tedious.
Also, it defeats the raison d'etre of libtool (to make it easy to
create various kinds of objects, across platforms/compilers) a bit,
doesn't it?
Well, another workaround that I used to recommend before 1.5.20 was
to just use CC="cc -flags .." during configure. Ugly, I know.
:)
Works I guess.
Are there possibly more system-dependent restrictions?
May PIE code end up in static libraries?
I can't see why not.
In non-PIE executables?
Yep, seems to work fine. Relocatable objects into a non-relocatable
executable should be possible just fine.
It's non-relocatable into a relocatable object which generally is
impossible, I /think/.
Well, because of the PIC analogy there may be a certain appeal to
this. OTOH, I believe a common need would be _users_ wishing to
have all their executables PIE,
ACK.
and thus would not want to change
more than, say, a change to CFLAGS and LDFLAGS and be done with it.
I'm not sure it is possible though.
Now I'm not certain what all will break. So for now we should not
allow that through -- someone using the -Wc, hack may be assumed to
know what he's doing.
How exactly though?
The flags to be passed depend on what is being linked. Only the
build system of the project concerned knows whether it is building a
shared library or an executable.
If the user specifies CFLAGS="-Wc,-fpie" LDFLAGS="-Wl,-pie", then
this will /fail/ for shared libraries. ;)
The project I'm interested in builds both shared libraries, static
libraries and executables. The latter link to the former obviously.
Which flags must be used, if you want PIE:
a) varies according to the end-usage of the objects being built
between PIE and PIC
b) varies between compile and link (gcc wants -fpic or -fpie, linker
wants -pie. Though, gcc does right thing if you specify both).
AFAICT, to support PIE builds it fundamentally requires the project
concerned to provide ability to supply different flags for build and
linking of objects intended for executables. One big hammer doesnt
work if the project also compiles shared libraries.
We can supply executable specific CFLAGS and LDFLAGS in our build
system. Be nice maybe though if libtool did this for us. ;)
BTW, libtool 1.5.18 does not seem to support -xtarget:
/bin/bash ../libtool --tag=CC --mode=link cc -xO4 -v -xspace
-xstrconst -Xt -xc99 -xipo=2 -xtarget=generic64 -o <output library>
-rpath /usr/local/quagga/lib -version 0:1:0 <all the .lo objects>
-lm -lresolv -lcrypt -lumem -lnsl -lsocket
cc -G -h libzebra.so.0 -o .libs/<output library>
.libs/<all the .lo objects> -lm -lresolv -lcrypt -lumem -lnsl -lsocket -lc
ld: fatal: file .libs/network.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to
.libs/<output library>
$ grep xtarget ../libtool
# -xarch=*, -xtarget=* enable 64-bit mode on the Sun compiler
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*)
$ ../libtool --version
ltmain.sh (GNU libtool) 1.5.18 (1.1220.2.246 2005/05/16 10:00:18)
However, I have a mish-mash of 1.5.18 stuff (e.g ltmain.sh) and 1.9
bits (eg libtool.m4 is serial 49 from 1.9 CVS) - to try avoid the
'check all the languages' problems. Not sure if thats the cause.
Cheers, Ralf
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
Fortune:
"It takes all sorts of in & out-door schooling to get adapted
to my kind of fooling"
- R. Frost
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool