GNU logs - #10005, boring messages

Message sent to bug-libtool@HIDDEN:

Subject: bug#10005: pyexec_... target's dependency (via LIBADD) on lib_... target not recognized
Resent-From: Frederik Heber <heber@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Wed, 09 Nov 2011 18:51:02 +0000
Resent-Message-ID: <handler.10005.B.132086460425652 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 10005 <at> debbugs.gnu.org
Message-ID: <4EBAC7DA.2080900@HIDDEN>
Date: Wed, 09 Nov 2011 19:35:06 +0100
From: Frederik Heber <heber@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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 sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Frederik Heber <heber@HIDDEN>
Subject: bug#10005: Acknowledgement (pyexec_... target's dependency (via
 LIBADD) on lib_... target not recognized)
Message-ID: <handler.10005.B.132086460425652.ack <at> debbugs.gnu.org>
References: <4EBAC7DA.2080900@HIDDEN>
X-Gnu-PR-Message: ack 10005
X-Gnu-PR-Package: libtool
Reply-To: 10005 <at> debbugs.gnu.org
Date: Wed, 09 Nov 2011 18:51:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-libtool@HIDDEN

If you wish to submit further information on this problem, please
send it to 10005 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
10005: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10005
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-libtool@HIDDEN:

Subject: bug#10005: pyexec_... target's dependency (via LIBADD) on lib_... target not recognized
Resent-From: Frederik Heber <heber@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 10 Nov 2011 14:53:01 +0000
Resent-Message-ID: <handler.10005.B.13209367584071 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 10005 <at> debbugs.gnu.org
Message-ID: <4EBBE518.7000104@HIDDEN>
Date: Thu, 10 Nov 2011 15:52:08 +0100
From: Frederik Heber <heber@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
References: <4EBAC7DA.2080900@HIDDEN>
In-Reply-To: <4EBAC7DA.2080900@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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)

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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