[Top][All Lists]

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

Re: 1.5.18: suppressing non-C language checks / pass flags to cc in link

From: Paul Jakma
Subject: Re: 1.5.18: suppressing non-C language checks / pass flags to cc in link mode
Date: Tue, 29 Nov 2005 06:59:40 +0000 (GMT)

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

- 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.


- 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


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.


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!

Paul Jakma      address@hidden  address@hidden  Key ID: 64A2FF6A
Vests are to suits as seat-belts are to cars.

reply via email to

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