automake
[Top][All Lists]
Advanced

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

libtool relink problem


From: Emmanuel Engelhart
Subject: libtool relink problem
Date: Wed, 29 Jun 2011 17:14:19 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10


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.

Here is the error:

========================================

libtool: relink: g++ -shared -nostdlib /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/../../../crti.o /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/crtbeginS.o .libs/libXapianAccessor_la-xapianAccessor.o .libs/libXapianAccessor_la-splitString.o .libs/libXapianAccessor_la-unaccent.o .libs/libXapianAccessor_la-searcher.o .libs/libXapianAccessor_la-xapianSearcher.o -Wl,-rpath -Wl,/home/kelson/moulinkiwix/kiwix-0.9/_inst/lib -L/usr/lib/xulrunner-devel-1.9.2.17/lib -lxpcomglue_s -lxul -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -L/tmp/am-dc-10007//tmp/am-dc-10007//usr/lib -L/usr/lib -lxapian -licui18n -licuuc -licudata -ldl -L/tmp/am-dc-10007//tmp/am-dc-10007//home/kelson/moulinkiwix/kiwix-0.9/_inst/lib -L/home/kelson/moulinkiwix/kiwix-0.9/_inst/lib -lctpp2 -llzma -lmicrohttpd -lclucene -lz -L/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2 -L/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/../../.. -L/usr/lib/i386-linux-gnu -lstdc++ -lm -lc -lgcc_s /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/crtendS.o /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/../../../crtn.o -shared -Wl,-soname -Wl,libXapianAccessor.so.0 -o .libs/libXapianAccessor.so.0.0.0
/usr/bin/ld: cannot find -lctpp2
collect2: ld returned 1 exit status

========================================


Here is the corresponding Makefile.am:

========================================
pkglib_LTLIBRARIES=libXapianAccessor.la
xptdir = ${DESTDIR}/${libdir}/kiwix/components/
pkglibdir = $(DESTDIR)/$(libdir)/kiwix/components
xpt_DATA = xapianAccessor.xpt
AM_CPPFLAGS=-I$(top_srcdir)/src/common -I$(top_srcdir)/src/ctpp2/include
libXapianAccessor_la_SOURCES= \
        xapianAccessor.cpp \
        ../../common/splitString.cpp \
        ../../common/unaccent.cpp \
        ../../common/kiwix/searcher.cpp \
        ../../common/kiwix/xapianSearcher.cpp
include_HEADERS= \
        ../../common/splitString.h \
        ../../common/unaccent.h \
        ../../common/kiwix/searcher.h \
        ../../common/kiwix/xapianSearcher.h
libXapianAccessor_la_CXXFLAGS=$(LIBCTPP2_CFLAGS) $(LIBXUL_CFLAGS) 
$(LIBXAPIAN_CFLAGS) $(LIBICU_CFLAGS) $(XPCOM_CFLAGS) -I../../common/ -D 
GECKO_VERSION=$(GECKO_VERSION)
if IS_OSX
libXapianAccessor_la_CXXFLAGS += -I/opt/local/include
libXapianAccessor_la_LDFLAGS=$(LIBXUL_LDFLAGS) $(LIBXAPIAN_STATIC_LDFLAGS) 
$(LIBCTPP2_STATIC_LDFLAGS) $(LIBICU_STATIC_LDFLAGS) $(XPCOM_LDFLAGS)
else
libXapianAccessor_la_LDFLAGS=$(LIBCTPP2_LDFLAGS) $(LIBXUL_LDFLAGS) 
$(LIBXAPIAN_LDFLAGS) $(LIBICU_LDFLAGS) $(XPCOM_LDFLAGS)
libXapianAccessor_la_LIBADD=$(top_builddir)/src/ctpp2/src/libctpp2.la
endif
EXTRA_DIST=IXapianAccessor.idl
BUILT_SOURCES=xapianAccessor.xpt IXapianAccessor.h
CLEANFILES=xapianAccessor.xpt IXapianAccessor.h *.lib *.obj *.dll

xapianAccessor.xpt:
        $(XPIDL) -m typelib -o xapianAccessor -I $(GECKO_IDL_PATH) 
$(top_srcdir)/src/components/xapianAccessor/IXapianAccessor.idl

IXapianAccessor.h:
        $(XPIDL) -m header -I $(GECKO_IDL_PATH) 
$(top_srcdir)/src/components/xapianAccessor/IXapianAccessor.idl
========================================


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

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

Regards
Emmanuel



reply via email to

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