Re: libtool relink problem
On Thu, 30 Jun 2011 14:38:49 +0200, Pippijn van Steenhoven wrote: On Wed, Jun 29, 2011 at 05:14:19PM +0200, Emmanuel Engelhart wrote: From: Pippijn van Steenhoven Date: Mon, Jun 20, 2011 at 4:55 PM Subject: Re: libtool relink problem To: automake@gnu.org 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/libtool@gnu.org/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). So problem was fixed by using the "noinst" prefix for the ctpp2 code. If I correctly have understood the autotools behaviour it seems that if you don't use "noinst" prefix, the autotools install the libraries. In our case this does not make sense as the *.la files are only linked one time during the software compilation and not used afterwards (for example from thirds projects). Thx you again Pippijn vor your help, without your answer I wouldn't have discover that the static lib were installed. Regards Emmanuel
Re: libtool relink problem
On Wed, Jun 29, 2011 at 05:14:19PM +0200, Emmanuel Engelhart wrote: > >> From: Pippijn van Steenhoven >> Date: Mon, Jun 20, 2011 at 4:55 PM >> Subject: Re: libtool relink problem >> To: automake@gnu.org >> >> >> 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/libtool@gnu.org/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 signature.asc Description: Digital signature
libtool relink problem
From: Pippijn van Steenhoven Date: Mon, Jun 20, 2011 at 4:55 PM Subject: Re: libtool relink problem To: automake@gnu.org 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/libtool@gnu.org/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,
Re: libtool relink problem
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/libtool@gnu.org/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. Cheers, -- Pippijn van Steenhoven signature.asc Description: Digital signature
libtool relink problem
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/libtool@gnu.org/msg00782.html Is there a solution available for this? Thanks Santhosh