GNU bug report logs - #10005
pyexec_... target's dependency (via LIBADD) on lib_... target not recognized

Previous Next

Full log

View this message in rfc822 format

From: Frederik Heber <heber <at> ins.uni-bonn.de>
To: 10005 <at> debbugs.gnu.org
Subject: bug#10005: pyexec_... target's dependency (via LIBADD) on lib_... target not recognized
Date: Thu, 10 Nov 2011 15:52:08 +0100

Hey there,

some small (but probably not unimportant) additional information:

This problem only occurs if make is launched with multiple threads (e.g.
-j4). With just a single thread the dependency is resolved correctly
(either by accident, or alphabetical ordering, or ...)

Kind regards,

Frederik

On 11/09/2011 07:35 PM, Frederik Heber wrote:
> Hey there,
> 
> My problem in short is:
> I have a project where multiple shared libraries among them a python
> module (pybar) (using boost::python) is created. However, the python
> module (pyexec_LT...) depends on one of the other shared libraries
> (lib_LT...) via ..._LIBADD. This dependency is not correctly recognized.
> Linking fails when executing make install.
> 
> It is similar to the problem described here
> (http://osdir.com/ml/automake-gnu/2010-03/msg00037.html), although there
> it occurs for the same target name, not in conjuction with pyexec_....
> 
> first the system info:
> libtool 2.2.6b (according to libtool --version)
> automake 1.11.1 (according to automake --version)
> Ubuntu 10.04, Linux bespin 2.6.32-34-generic ... x86_64 GNU/Linux
> (according to uname)
> 
> m4 macros:
> boost is checked via tsuna's boost.m4 from
> https://github.com/tsuna/boost.m4 (setting all BOOST_...)
> ax_python.m4 checks for python presence (setting PYTHON_...)
> 
> 
> The essential parts from Makefile.am are as follows:
> ....
> lib_LTLIBRARIES += libfooUI.la
> libfoo_la_CPPFLAGS = ${BOOST_CPPFLAGS}
> libfoo_la_LDFLAGS = $(AM_LDFLAGS) $(BOOST_FILESYSTEM_LDFLAGS)
> $(BOOST_PROGRAM_OPTIONS_LDFLAGS) $(BOOST_RANDOM_LDFLAGS)
> $(BOOST_SYSTEM_LDFLAGS) $(BOOST_THREAD_LDFLAGS)
> $(BOOST_FILESYSTEM_LDFLAGS) $(BOOST_PROGRAM_OPTIONS_LDFLAGS)
> $(BOOST_RANDOM_LDFLAGS) $(BOOST_SYSTEM_LDFLAGS) $(BOOST_THREAD_LDFLAGS)
> libfoo_la_LIBADD = \
> 	.. just convenience libraries ...
> ...
> pyexec_LTLIBRARIES += pybar.la
> pybar_la_SOURCES = \
>         bar.cpp \
>         bar.hpp \
> pybar_la_CPPFLAGS = ${BOOST_CPPFLAGS} -I$(PYTHON_INCLUDE_DIR)
> pybar_la_LDFLAGS = -module -avoid-version -shared
> pybar_la_LIBADD = \
>         libfoo.la
>         $(BOOST_PYTHON_LDFLAGS) $(BOOST_PYTHON_LIBS) \
>         -l$(PYTHON_LIB)
> ...
> 
> The problem is then when calling make install:
> /usr/bin/ld: cannot find -lfoo
> collect2: ld returned 1 exit status
> libtool: install: error: relink `pybar.la' with the above command before
> installing it
> make[4]: *** [install-pyexecLTLIBRARIES] Error 1
> make[4]: *** Waiting for unfinished jobs....
> 
> I.e. libtool (automake) does not seem to recognize the dependency of the
> shared libraries pybar on libfoo because of the different prefixes lib_
> and pyexec_: libfoo has not been relinked at this point yet. pybar is
> re-linked too early. The problem disappears if the python module is
> (wrongly) given among the lib_LTLIBRARIES.
> 
> This first rears its head during re-linking with the install target (and
> with the final link dir via -L given to ld), normal 'make all' produces
> both libraries just fine.
> 
> Is this known? Is this a bug? Is there a workaround? Can I do anything
> more to assist?
> 
> 
> Kind regards,
> 
> 
> Frederik


-- 
Dipl.Phys. Frederik Heber
Wegelerstrasse 6/5.011, 53115 Bonn
Tel.: +49 228 73 3866
(Arbeitsgruppe Prof. Dr. M. Griebel)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.