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

[Paul Jakma]

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

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.

Ok.

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

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.

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.
>
> >         -xtarget=....
>
> Ditto.

Ah excellent!

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

Welcome!

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