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

Previous Next

To reply to this bug, email your comments to 10005 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Frederik Heber <heber <at> ins.uni-bonn.de>
To: bug-libtool <at> gnu.org
Subject: pyexec_... target's dependency (via LIBADD) on lib_... target not
	recognized
Date: Wed, 09 Nov 2011 19:35:06 +0100

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)

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Frederik Heber <heber <at> ins.uni-bonn.de>
To: bug-libtool <at> gnu.org
Subject: Re: 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.