libtool
[Top][All Lists]
Advanced

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

Re: help with C API in C++ static library


From: Jason Kraftcheck
Subject: Re: help with C API in C++ static library
Date: Fri, 15 Jan 2010 16:08:29 -0600
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)

Ralf Wildenhues wrote:
> Hello Jason,
> 
> * Jason Kraftcheck wrote on Fri, Jan 15, 2010 at 07:10:21PM CET:
>> I am trying to build a static library that is implemented in C++ and has a C
>> API.  The resulting .la does not appear to include any information
>> indicating that the library needs to be either linked with C++ or explicitly
>> include the C++ runtime libraries.  Thus when I try to link a simple test
>> application written in C, the link step fails because of unresolved symbols
>> provided by the C++ runtime libraries.  What are my options at this point?
>> The ideal solution (for me) would be for libtool to include the C++ runtime
>> libraries in dependency_libs for the .la.  Is this possible?
> 
> Not really.  Your easiest bet is to just use the C++ compiler driver to
> link the test application.
> 
> In case you are using Automake, you can force the C++ linker for
> otherwise C code with something like
>   if FALSE
>   nodist_prog_SOURCES += dummy.cpp
>   endif
> 
> or, more generally, by overriding prog_LINK or LINK.
> 

Thanks for the reply (both Ralf and Bob.)

Linking with the C++ compiler would address my immediate problem of linking
my test code, by still produces a library intended to be linked with C code
that requires using the c++ compiler to link.  I had hoped that libtool's
.la files would provide the same feature for static libraries as the shared
library dependency list.

Why doesn't libtool include necessary runtime libraries in the
dependency_libs field of .la files?  I understand that historically there
were other issues like initialization of static/global data in C++ code.  Is
that still an issue on some platforms?  The GNU compiler seems to handle
this correctly for a simple test case.

Any suggestions on a robust mechanism to detect runtime libraries so that I
can specify them explicitly?  My first thought was to link a simple shared
library with libtool during the configure process and run ldd on it.
However, this won't work for later versions of libtool because the libtool
script isn't generated until the end of the configure script.

Again, thanks,

- jason








reply via email to

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