libtool
[Top][All Lists]
Advanced

[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: Ralf Wildenhues
Subject: Re: 1.5.18: suppressing non-C language checks / pass flags to cc in link mode
Date: Sun, 27 Nov 2005 19:02:20 +0100

Hi Paul,
* Paul Jakma wrote on Sat, Nov 26, 2005 at 02:00:03PM CET:
On Sat, 26 Nov 2005, Ralf Wildenhues wrote:
>[ BTW, Paul, I believe you mail setup is a bit broken.  Please do not
>set Mail-Followup-To: to your mail address only, if you want the mailing
>list to be included. At least mutt needs manual override for this. ] Sure, just point me to an RFC describing how to correctly configure that header. ;)

I hoped you would not say that.. ;-)
>Should work already if you use `-Wc,x,y,z' or `-Wl,x,y,z', unless I >am missing something obvious. Your example does not work because >arguments with spaces are legitimate.
Ah, oh dear. Weird, those are quite rare presumably?

As in
-DPACKAGE_STRING=\"foo\ 0.1\"
for example?  Granted, I don't know of so many linker flags which need
this.
The Wc method won't work for all flags though, I think. (And is a bit tedious too).

Which? Please show.
libtool 1.5 recognising the flags I'm interested in and passing them through would do the trick (I've already read below where you say 1.5.20 already recognises some of the SOS flags I'm interested in).

Well, another workaround that I used to recommend before 1.5.20 was
to just use CC="cc -flags .." during configure. Ugly, I know.
>>Well, a libtool autoconf macro to specify the CClink flags to use
>>might be nice.

The above /might/ do what I want, at least wrt being able to specify CClink flags common to all objects (eg -m64 or -xtarget=generic64). However, see below - it wouldn't quite work for PIC versus PIE I think.

Right.
>For position-independent executables, we have a TODO item.

I think part of this /maybe/ falls in the remit of automake. It is the one which determines whether a set of objects are to be compiled into a shared object, which into an executable. Ie, the following should work (untested ;) ): lib_LTLIBRARIES = libinternal.la libexported.la
libinternal_la_LDFLAGS = -release $(PROG_CFLAGS)
libexported_la_LDFLAGS = -version x:y:z
bin_PROGRAMS = foo
foo_SOURCES = main.c
foo_CFLAGS = $(PROG_CFLAGS)
foo_LDADD = libinternal.la libexported.la PROG_CFLAGS would contain -fpie -pie. PIC objects can be linked together with PIE objects into a PIE executable, i think. PIE can not be linked into a shared object.

Are there possibly more system-dependent restrictions?
May PIE code end up in static libraries? In non-PIE executables?
Another alternative, if libtool wishes to abstract the PIE flag as it does PIC, would be to add an additional mode flag to libtool to compile PIE objects - then teach automake to use libtool even for compiling non-shared objects, though even that could be done as a static library I guess.

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, and thus would not want to change more than, say, a
change to CFLAGS and LDFLAGS and be done with it.  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.
Cheers,
Ralf




reply via email to

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