On Tue, 29 Nov 2005, Ralf Wildenhues wrote:
Nono. You are missing the fact that Autoconf will put this in
@DEFS@ if AC_CONFIG_HEADERS has not been used.
Ah! :)
Surely noone would pass those to a link command, right? ;-) (I
mean even if they don't use Automake.)
Hehe, hope not! ;)
You are missing the point here: the `-Wc,' `-Wl,' are *only* for
libtool. The compiler won't see it ever. Libtool will mangle it so
the compiler sees the following flags only. Libtool will even put
in the right $wl flag if necessary.
Ah right, got you. I meant though it is tedious for the user to have
to set Wc and Wl individually.
Works pretty well for the ABI stuff (-xarch etc).
Yes, it should. /me tests -> yep, works! Great.
I'm not convinced -- yet. libtool can do lots of munging,
including removing -fpie from the command line. It's only the
non-libtool compiled stuff we have to get right for Automake or
non-Automake using projects.
Well, when I talk about decent PIE support in libtool, I mean you
should *not* need -Wc, or -Wl, *then*. Those flags are a kludge,
and if you use them, you are supposed to know what you are doing.
:)
Yes, it'd be nice to have PIE support.
As far as I can see it, libtool could support PIE reasonably well by
simply:
- have the user
configure CFLAGS=-fpie LDFLAGS-pie
- ignoring completely -fpie during compilation
- not ignoring it when linking a program
:)
That could work, yes, but /only/ if the user selects --with-pic.
Objects /must/ be compiled as either PIC or PIE in order to be later
linked together into a PIE executable.
Alternatively, the second step would need to say:
- pass -fpie during compilation, if -fpie is detected in CFLAGS.
or:
- pass -fpic always
Second possibility: the user could have created main.lo and linked that
directly into the program, although he shouldn't. So let's fix above to
- ignoring completely -pie -fpie during compilation of the PIC object,
if any, but applying it to the non-PIC object, if any.
- ignoring both during linking of a library
- not ignoring both when linking a program
Right.
Remaining questions:
- some projects employ assembler hackery that relies on, and creates
different code, depending upon -DPIC. They'll probably have to
adjust, but in any case it may be nice for them to know. Does -fpie
#define something they can use?
- How portable is this whole thing? I mean, does PIE work on AIX, where
we do not even create non-PIC objects?
I think it needs runtime dynamic linker support, otherwise you can
not execute the resulting binary ;).
Sure. I believe my scheme outlined above, implemented in libtool,
would simply solve all your problems. Right? What's missing?
I think it would, yes, just about - if you compile PIC at least.
BTW, libtool 1.5.18 does not seem to support -xtarget:
Repeating myself: fixed in branch-1-5 after 1.5.20. Fixed in HEAD.
Oops, d'oh! Sorry! :)
Yes, there was a bogus `test $with_gcc = yes' a couple of lines
down the road that we missed out when backporting from HEAD.
Among others.
Ah.
This is very explicitly NOT supported! Don't mix libtool.m4 and
ltmain from different Libtool versions! CVS HEAD even has a test
to prevent this.
I know, I get to keep both pieces if it breaks. :)
I won't invest any work in finding this out, neither will I accept
any bug reports that result from this mix.
ACK - wouldn't expect you to. Sorry about that ;).
use either branch-1-5 or HEAD. If you're scared to use from CVS
HEAD, please use one of the temporary workarounds posted on this
list for the C++/F77 checks.
Apologies, using CVS bits was my previous workaround for the C++/F77
checks. ;) I'll try use a 1.5 workaround. Though, I don't mind using
CVS libtool presuming it generally works / isn't known to be broken.
Vielen dank Ralf!
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
Fortune:
Vests are to suits as seat-belts are to cars.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
