[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: Sat, 26 Nov 2005 13:00:03 +0000 (GMT)

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

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?

The Wc method won't work for all flags though, I think. (And is a bit tedious too).

ltmain is mostly responsible. And if you can describe all your needs, we can fix them.

I'll try. ;)

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

The last two I might understand, but why do you ever need -fpic/-fPIC?
Libtool should add these itself in the right cases.


For position-independent executables, we have a TODO item. I haven't looked closely at the semantics nor understood it completely. If someone can help out here or point at good documentation, great! (What happens if you have partially PIC, partially PIE code, which parts need to be compiled PIE/linked PIE, on which systems, what happens if you try to link in non-PIC code...)

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


libinternal_la_LDFLAGS = -release $(PROG_CFLAGS)
libexported_la_LDFLAGS = -version x:y:z

bin_PROGRAMS = foo
foo_SOURCES = main.c
foo_LDADD =

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.

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.

Is allowed through by 1.5.20.
There is a related fix in branch-1-5 not in 1.5.20 though.



Ah excellent!

For the others I need to check documentation first (thanks for the
pointer!), will reply later.


Paul Jakma      address@hidden  address@hidden  Key ID: 64A2FF6A
"Earth is a great, big funhouse without the fun."
                -- Jeff Berner

reply via email to

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