automake
[Top][All Lists]
Advanced

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

Re: libtool relink problem


From: Pippijn van Steenhoven
Subject: Re: libtool relink problem
Date: Thu, 30 Jun 2011 14:38:49 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Jun 29, 2011 at 05:14:19PM +0200, Emmanuel Engelhart wrote:
>
>> From: Pippijn van Steenhoven<address@hidden>
>> Date: Mon, Jun 20, 2011 at 4:55 PM
>> Subject: Re: libtool relink problem
>> To: address@hidden
>>
>>
>> On Sun, Jun 19, 2011 at 03:40:06PM +0530, Santhosh Thottingal wrote:
>>> Hi,
>>> I am facing a problem with libtool. While installing it complains  a
>>> relink  required and while doing so it tries to link against the
>>> shared library instead of static library.
>>> Well, the problem is better explained in this thread
>>> http://sourceware.org/ml/automake/2004-07/msg00127.html with example
>>> code.
>>>
>>> I am facing exactly the same problem.
>>>
>>> I saw a similar problem in this thread also
>>> http://www.mail-archive.com/address@hidden/msg00782.html
>>>
>>> Is there a solution available for this?
>>>
>>>
>>> Thanks
>>> Santhosh
>>>
>> Hi Santhosh,
>>
>> I suggest writing your *_LTLIBRARIES with a comment in front, perhaps
>> with #>  to differ between disabled and enabled libraries. Then using
>> grep(1) to extract the names and the same tools to extract the
>> dependencies. You can then use tsort(1) to topologically sort the
>> libraries and write the actual ${dir}_LTLIBRARIES to an included .am
>> file. Semantically, this is what I do. In reality, I wrote a preprocessor
>> for automake that does this, but I don't suggest using it, as it's beta
>> and very much tailored to my needs.
> Hi Pippijn
>
> Thank you for taking time and trying to help us... because we really get  
> stucked.
>
> I tried to understand your answer but I honestly think I'm not good  
> enough with automake to be able to understand and apply your  
> methodology. I also doubt that the other cases given by Santhosh are the  
> same as our, although the symptom is.
>
> From my understanding the previously described issues occur if the  
> dependences are not compiled in the right order. I think this is not our  
> problem because at the moment the error occurs, I know the dependence is  
> already compiled.

The issue occurs if the dependencies are not _installed_ in the right
order.

> So, I'm sure the file $(top_builddir)/src/ctpp2/src/libctpp2.la exists.

As you noted, the dependency has been compiled and linked, but for
installation, it has to be relinked:

> libtool: relink: g++ -shared -nostdlib  
           ^^^^^^

The above occurs in make install.

> So my question is why automake replaces the path with libcttp2.la in  
> -lctpp2, replacing a static linking with a dynamic one?

It's related to rpath linking. The resulting binaries are relinked to
include $(libdir) as rpath, so that installed binaries can be called and
libraries loaded without listing $(libdir) in LD_LIBRARY_PATH or
ld.so.conf.

It looks like you are using a recursive make, in your project. Are you
sure that libcttp2.la exists in $(libdir)? As an experiment, try make
install in libctpp2's $(builddir) and then make install in
$(top_builddir).

Regards,
-- 
Pippijn van Steenhoven

Attachment: signature.asc
Description: Digital signature


reply via email to

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