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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
