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

[Paul Jakma]

On Sun, 27 Nov 2005, Ralf Wildenhues wrote:

> I hoped you would not say that..  ;-)

:). It's a bad header. It's described slightly differently by DJB and 
an old DRUMS draft. Of the MUAs which interpret it, their actions 
seems to differ. Those MUAs should stop supporting it really. Anyway, 
a matter for another list (or private mail ;) ).

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

#ifdef WANT_SPECIAL_FOO
#define PACKAGE_STRING "foo 0.1"
#else /* WANT_NEW_FOO */
#ifdef WANT_FOO
#define PACKAGE_STRING "foo 0.2"
#endif /* WANT_FOO */
#endif /* WANT_NEW_FOO */

And avoid the quoted define passed as -D argument.

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

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?

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

> Are there possibly more system-dependent restrictions?
> May PIE code end up in static libraries?

I can't see why not.

> In non-PIE executables?

Yep, seems to work fine. Relocatable objects into a non-relocatable 
executable should be possible just fine.

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

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

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

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.

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:

 /bin/bash ../libtool --tag=CC --mode=link cc  -xO4 -v -xspace 
-xstrconst -Xt -xc99 -xipo=2 -xtarget=generic64   -o <output library> 
-rpath /usr/local/quagga/lib -version 0:1:0 <all the .lo objects>
-lm -lresolv -lcrypt  -lumem -lnsl -lsocket

cc -G -h libzebra.so.0 -o .libs/<output library>
.libs/<all the .lo objects> -lm -lresolv -lcrypt -lumem -lnsl -lsocket -lc
ld: fatal: file .libs/network.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to 
.libs/<output library>

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

$ ../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. Not sure if thats the cause.

> Cheers, Ralf

regards,
--
Paul Jakma      address@hidden  address@hidden  Key ID: 64A2FF6A
Fortune:
"It takes all sorts of in & out-door schooling to get adapted
to my kind of fooling"
- R. Frost