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

[Ralf Wildenhues]

Hi Paul,

* Paul Jakma wrote on Tue, Nov 29, 2005 at 05:01:26AM CET:
> On Sun, 27 Nov 2005, Ralf Wildenhues wrote:
> 
> >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:

Nono.  You are missing the fact that Autoconf will put this in @DEFS@ if
AC_CONFIG_HEADERS has not been used.  Surely noone would pass those to a
link command, right?  ;-)
(I mean even if they don't use Automake.)

> And avoid the quoted define passed as -D argument.

See above.

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

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.

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

That's why we're having this discussion, to improve 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.

Works pretty well for the ABI stuff (-xarch etc).

> >Are there possibly more system-dependent restrictions?
> >May PIE code end up in static libraries?
> 
> I can't see why not.

OK.

> >In non-PIE executables?
> 
> Yep, seems to work fine. Relocatable objects into a non-relocatable 
> executable should be possible just fine.

OK.

> It's non-relocatable into a relocatable object which generally is 
> impossible, I /think/.

Yes, true.

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

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.

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

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.

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

:)

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?

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

Sure.  I believe my scheme outlined above, implemented in libtool,
would simply solve all your problems.  Right?  What's missing?

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

Repeating myself: fixed in branch-1-5 after 1.5.20.  Fixed in HEAD.

> $ 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*)

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.

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

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.  

> Not sure if thats the cause.

I won't invest any work in finding this out, neither will I accept any
bug reports that result from this mix.  Libtool work is sometimes
daunting because of the mix of so many different things and their
versions; the interface between ltmain and libtool.m4 is one thing we
rely on matching exactly.  Please 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.

Cheers,
Ralf