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

[Ralf Wildenhues]

Hi Paul, Mike,

* Paul Jakma wrote on Sat, Nov 26, 2005 at 07:17:10AM CET:
> 
> Is there any sane way to have libtool pass on CFLAGS to cc in link 
> mode?
> 
> Libtool seems to trust it's own knowledge of what CFLAGS the compiler 
> should use in link mode beyond anything supplied by the user in 
> CFLAGS. There is a workaround it seems -XCClinker <flag>, but it 
> is problematic: If you have a number of options which CC must be 
> passed during link mode, it becomes quite unmanageable.

Well, in a way libtool *cannot* allow all flags through, and thus *has*
to know about them.  At least it has to know whether a certain flag eats
an argument or not.  And it cannot allow flags through without knowing,
when those flags alter linking behavior which libtool assumes
differently.  Also note that on some systems $LD is used for linking
rather than $CC or $CXX.

> E.g: If you set CFLAGS to include -XCClinker ... then configure's 
> 'does compiler work?' test fails (because it invokes cc directly).

Yep, unfortunately.  LDFLAGS is not quite right either.  Setting it in
the Makefile only helps, or..

> The only other alternative then, it seems, is to write your configure 
> script to include some kind of extra 'LINK_MODE_CFLAGS' variable, 
> then tack that on to CFLAGS and also generate an additional 
> 'LI5BBTOOL_CCLINK_FLAGS' variable for each word in LINK_MODE_CFLAGS 
> combined with -XCClinker and then use LIBTOOL_CCLINK_FLAGS in 
> prog_LDADD in your Makefile.am's.

something like this, yes.  It would be nice to adjust Autoconf/Automake
to cope better with this situation.

> That's quite convoluted, and would not be neccessary if libtool would 
> just pass on the flags. Why doesn't it? (Buggy compilers which won't 
> take the same flags for compile and link modes?).

Which flags do you need passed through?

> The problem is that it isn't uncommon to have compiler flags which 
> must be specified at both compile and link time. E.g. flags 
> controlling incremental linking, inter-object link optimisation, 32 
> or 64 bit ABIs, etc.

We should deal with all those correctly.  Please list the ones we're
currently missing, so that can be fixed.

> Is it the idea that the sane way for libtool to work is to have 
> /intimate/ knowledge of each compiler and each platform? :) (I know 
> the idea is to try abstract things a bit, but to the point of making 
> it impossible to easily build 64bit binaries? ;) )

As I said: list them and we'll see.


> Problem 2:
> 
> I tried to upgrade to a 1.5.18 in order to see if Problem 1 had been 
> addressed at all (i had been using 1.5.6 i think - perhaps with some 
> m4 files from CVS circa 2004 which dont have this problem). However, 
> I found that there still does not seem to be a way to suppress 
> libtool's desire to check for every possible language known to 
> computer science.

* Mike Frysinger wrote on Sat, Nov 26, 2005 at 08:50:33AM CET:
> 
> 1.5.20 (and earlier) do not allow you to change this behavior ...
> afaik, this has not be resolved in cvs either ...

Well, in fact this _has_ been fixed in CVS HEAD.  For a long time.
In fact so long that I believe it was fixed even before I started
reading the libtool mailing lists or otherwise be interested in Libtool,
less working on it.  I can't find the patch in my archives.

> what i do (and what has worked with 1.5.20 and older) is this:
> http://lists.gnu.org/archive/html/libtool/2005-09/msg00098.html

This patch is a decent workaround.

I'm inclined to accept a fix for branch-1-5 if somebody has the patience
to dig out the patch that fixed this in CVS HEAD (plus eventual
subsequent fixes of the patch) and it can be applied to branch-1-5
without adding new interfaces or changing existing ones, and is not too
disruptive in general.  If merely for the reason that I hate to read yet
another bug report about this issue, or see yet another dysfunctional
workaround for this (unlike above!).

Other than that, I can only reiterate that we are working on the last
few known issues in CVS HEAD, hope to have them fixed in the not too
distant future, and will then release another 2.0 alpha, and 2.0
hopefully soon afterwards.  Yes, I know I sound like a street organ. :-/

Cheers,
Ralf