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

[Paul Jakma]

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      address@hidden  address@hidden  Key ID: 64A2FF6A
Fortune:
Vests are to suits as seat-belts are to cars.