[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Jakma
Subject: 1.5.18: suppressing non-C language checks / pass flags to cc in link mode
Date: Sat, 26 Nov 2005 06:17:10 +0000 (GMT)


I have a problem (2 actually ;) ).

Problem 1:

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.

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

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

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

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.

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

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.

It's annoying to get bug reports from users unable to build the software due to their C++, Fortran, whatever compiler not working correctly, particularly when the software concerned is C..

I tried setting up ala:


but that didnt work. Some of the other auto* tools seem to be unhappy that I'm not using AC_PROG_LIBTOOL. :( Whats the way to get what I want (other than by hacking _AC_PROG_LIBTOOL to remove the CXX, F77 and GCJ macros)?

I'm using automake 1.9.5 and autoconf 2.59.

Paul Jakma      address@hidden  address@hidden  Key ID: 64A2FF6A
Karl's version of Parkinson's Law:  Work expands to exceed the time alloted it.

reply via email to

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