[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 lin

From: Paul Jakma
Subject: Re: 1.5.18: suppressing non-C language checks / pass flags to cc in link mode
Date: Tue, 29 Nov 2005 04:01:26 +0000 (GMT)

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

Ouch, that's fairly nasty. If someone wants to do this, it'd be easier to do:

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


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


$ ../libtool --version (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 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

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

reply via email to

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