[Top][All Lists]

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

Overriding linker command on a per-makefile basis?

From: Kristian Nielsen
Subject: Overriding linker command on a per-makefile basis?
Date: Wed, 06 Jan 2010 14:08:08 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

I have a project using Automake (with multiple's) and libtool.
This project is built with CXX=gcc.

I would like to override the command used to link a shared library in a
specific (to link with g++ rather than gcc).

I found I could do this in


(In I set OQGRAPH_CXX to "g++").

This sort of partly works, as it passes the g++ to libtool:

    ../../libtool --tag=CXX --mode=link g++ -rdynamic -o ...

But libtool still uses gcc to link the resulting .so:

    gcc -shared .libs/oqgraph_engine_la-ha_oqgraph.o -Wl,-soname 
-Wl, -o .libs/ ...

Because of this, the resulting .libs/ is missing a link
dependency to libstdc++.

>From what I can see, the command used for linking is hard-coded inside the
libtool script to the value of CXX when the libtool script is generated during
configure. If there was a --cxxld option for libtool it seems it would solve
my problem, but that does not appear to be the case ...

So is there any other way that I can link most of the executables and
libraries in the project with gcc, but use g++ in one subdirectory?

I am using automake 1.9.6, autoconf 2.61, and libtool 1.5.26 (but need to
preferably support a range of versions).

Background: This is for MariaDB (a branch of the MySQL source code).

The core server code is often linked with gcc rather than g++ (CXX=gcc), even
though much of it is written in C++. This is historical (the code is carefully
written to not utilise C++ features that need the C++ runtime libraries), and
avoids dependencies on libstdc++ (and

However, now we are starting to see plugins that do need the C++ runtime
libraries, and surely more will appear over time. So we need a way to support
plugins which use libstdc++.

Plugins are configured with custom autoconf macros from inside,
so using separate ./configure in subprojects (with separate CXX variable)
seems not to be an option.

I was hoping to find a way to change CXX on a per-makefile basis, but CXX
looks pretty much a global setting for the project...

A further complication is that we do not _always_ build with GCC, for example
the Sun and Intel compilers are also supported IIRC.

The only thing I could think of is globally setting CXX to a wrapper script
which calls $REAL_CC or $REAL_CXX depending on some flag passed, which could
work but I would prefer some less intrusive method.

(An alternative is to just give up on linking with gcc and link the whole
project with g++ and accept the additional dependencies and deal with any
issues that arise. But I wanted to check if an alternative way is possible
before going this route).

 - Kristian.

reply via email to

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