cross / slibtool

Clone
Source Code
GIT

#71 Out of order libtool archives with static only builds fails
Closed 2 months ago by orbea. Opened 2 months ago by orbea.

Closed
Reopen Issue

slibtool: 15782cd
ola: 0.10.9

After issue #70 was fixed it exposed the next issue with ola.

When building ola with --disable-shared so that only static archives are linked it fails with undefined references.

rdlibtool: lconf: {.name="libtool"}.
rdlibtool: fdcwd: {.fdcwd=AT_FDCWD, .realpath="/tmp/ola-0.10.9"}.
rdlibtool: lconf: fstatat(AT_FDCWD,".",...) = 0 {.st_dev = 30, .st_ino = 1140}.
rdlibtool: lconf: openat(AT_FDCWD,"libtool",O_RDONLY,0) = 3.
rdlibtool: lconf: found "/tmp/ola-0.10.9/libtool".
rdlibtool: link: g++ examples/ola-client.o -I./include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden -Werror -Wno-error=deprecated-declarations -g -O2 -std=gnu++11 common/.libs/libolacommon.a -lresolv -lprotobuf ola/.libs/libola.a -lresolv -lprotobuf -o examples/.libs/ola_dev_info
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): warning: relocation against `_ZTVN3ola5proto17PluginListRequestE' in read-only section `.text.unlikely'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `ola::client::OlaClientCore::Setup()':
/tmp/ola-0.10.9/ola/OlaClientCore.cpp:78:(.text+0x1011): undefined reference to `ola::rpc::RpcChannel::RpcChannel(ola::rpc::RpcService*, ola::io::ConnectedDescriptor*, ola::ExportMap*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `std::auto_ptr<ola::rpc::RpcChannel>::reset(ola::rpc::RpcChannel*)':
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/backward/auto_ptr.h:250:(.text+0x1027): undefined reference to `ola::rpc::RpcChannel::~RpcChannel()'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `ola::client::OlaClientCore::Setup()':
/tmp/ola-0.10.9/ola/OlaClientCore.cpp:83:(.text+0x104c): undefined reference to `ola::proto::OlaServerService_Stub::OlaServerService_Stub(ola::rpc::RpcChannel*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `std::auto_ptr<ola::rpc::RpcChannel>::reset(ola::rpc::RpcChannel*)':
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/backward/auto_ptr.h:250:(.text+0x10b7): undefined reference to `ola::rpc::RpcChannel::~RpcChannel()'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `std::auto_ptr<ola::rpc::RpcChannel>::~auto_ptr()':
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/backward/auto_ptr.h:176:(.text+0x1136): undefined reference to `ola::rpc::RpcChannel::~RpcChannel()'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `ola::proto::RDMResponse::_internal_source_uid() const':
/tmp/ola-0.10.9/./common/protocol/Ola.pb.h:11594:(.text+0x14b7): undefined reference to `ola::proto::_UID_default_instance_'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `ola::proto::RDMResponse::_internal_dest_uid() const':
/tmp/ola-0.10.9/./common/protocol/Ola.pb.h:11684:(.text+0x156f): undefined reference to `ola::proto::_UID_default_instance_'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: ola/.libs/libola.a(libola_la-OlaClientCore.o): in function `ola::rdm::RDMResponse::RDMResponse(ola::rdm::UID const&, ola::rdm::UID const&, unsigned char, unsigned char, unsigned char, unsigned short, ola::rdm::RDMCommand::RDMCommandClass, unsigned short, unsigned char const*, unsigned int)':

This is because slibtool is given the .la files common/libolacommon.la and ola/libola.la out of order as provided from automake.

rdlibtool --tag=CXX --mode=link g++ -I./include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden -Werror -Wno-error=deprecated-declarations -g -O2 -std=gnu++11 -o examples/ola_dev_info examples/ola-client.o common/libolacommon.la ola/libola.la

In ola/Makefile.mk a dependency for libolacommon.la is added for libola.la.

ola_libola_la_LIBADD = common/libolacommon.la

But a dependency for libola.la is never added to libolacommon.la anywhere.

In ola/.libs/libola.a.slibtool.deps it shows liibolacommon.la as a dependency.

# makefile target: ola/libola.la
# slibtool target: ola/.libs/libola.a
# cprocess fdcwd:  /tmp/ola-0.10.9/build
# makefile target: common/libolacommon.la
# slibtool target: common/.libs/libolacommon.a
# cprocess fdcwd:  /tmp/ola-0.10.9/build
-lresolv
# makefile target: common/protocol/libolaproto.la
# slibtool target: common/protocol/.libs/libolaproto.a
# cprocess fdcwd:  /tmp/ola-0.10.9/build
-lprotobuf
#
# makefile target: common/libolacommon.la
-lprotobuf
-lprotobuf

However libola.la is NOT shown as a dependency in common/.libs/libolacommon.a.slibtool.deps.

# makefile target: common/libolacommon.la
# slibtool target: common/.libs/libolacommon.a
# cprocess fdcwd:  /tmp/ola-0.10.9/build
-lresolv
# makefile target: common/protocol/libolaproto.la
# slibtool target: common/protocol/.libs/libolaproto.a
# cprocess fdcwd:  /tmp/ola-0.10.9/build
-lprotobuf
#
# makefile target: common/libolacommon.la
-lprotobuf
-lprotobuf

Yet the link command places common/.libs/libolacommon.a before ola/.libs/libola.a and so it fails.

g++ examples/ola-client.o -I./include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden -Werror -Wno-error=deprecated-declarations -g -O2 -std=gnu++11 common/.libs/libolacommon.a -lresolv -lprotobuf ola/.libs/libola.a -lresolv -lprotobuf -o examples/.libs/ola_dev_info

However it will work when the dependee ola/.libs/libola.a is placed before any dependencies such as common/.libs/libolacommon.a.

So the following linker command DOES work.

g++ examples/ola-client.o -I../include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden -Werror -Wno-error=deprecated-declarations -g -O2 -std=gnu++11 ola/.libs/libola.a common/.libs/libolacommon.a -lresolv -lprotobuf common/protocol/.libs/libolaproto.a -lprotobuf -o examples/.libs/ola_dev_info

Additionally reversing the order of the .la files in the slibtool command also DOES work.

rdlibtool --tag=CXX --mode=link g++ -I./include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden -Werror -Wno-error=deprecated-declarations -g -O2 -std=gnu++11 -o examples/ola_dev_info examples/ola-client.o ola/libola.la common/libolacommon.la

However it is the responsibility of the libtool implementation to place dependencies in the correct order and not the Makefile.

This is possibly a more common issue, but there aren't many users for --disable-shared + slibtool so its easy to overlook.

I think this is the consequence of the commit that fixed the previous ola issue.

rdlibtool --tag=CXX --mode=link g++ -I../include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden -Werror -Wno-error=deprecated-declarations -Werror -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=sign-compare -g -O2 -std=gnu++11 -version-info 1:1:0 -o ola/libola.la -rpath /usr/local/lib ola/libola_la-AutoStart.lo ola/libola_la-ClientRDMAPIShim.lo ola/libola_la-ClientTypesFactory.lo ola/libola_la-Module.lo ola/libola_la-OlaCallbackClient.lo ola/libola_la-OlaClient.lo ola/libola_la-OlaClientCore.lo ola/libola_la-OlaClientWrapper.lo ola/libola_la-StreamingClient.lo common/libolacommon.la

rdlibtool: lconf: {.name="libtool"}.
rdlibtool: fdcwd: {.fdcwd=AT_FDCWD, .realpath="/tmp/ola-0.10.9/build"}.
rdlibtool: lconf: fstatat(AT_FDCWD,".",...) = 0 {.st_dev = 30, .st_ino = 206275}.
rdlibtool: lconf: openat(AT_FDCWD,"libtool",O_RDONLY,0) = 3.
rdlibtool: lconf: found "/tmp/ola-0.10.9/build/libtool".
rdlibtool: link: ln -s libola.so.def ola/.libs/libola.so.def.linux
rdlibtool: link: ln -s libola.so.def.linux ola/.libs/libola.so.def.host
rdlibtool: link: ar -crs ola/.libs/libola.a ola/libola_la-AutoStart.o ola/libola_la-ClientRDMAPIShim.o ola/libola_la-ClientTypesFactory.o ola/libola_la-Module.o ola/libola_la-OlaCallbackClient.o ola/libola_la-OlaClient.o ola/libola_la-OlaClientCore.o ola/libola_la-OlaClientWrapper.o ola/libola_la-StreamingClient.o
rdlibtool: link: ln -s /dev/null ola/.libs/libola.so.def
rdlibtool: link: ln -s /dev/null ola/.libs/libola.so.disabled
rdlibtool: link: ln -s ../libola.la ola/.libs/libola.la
rdlibtool: link: ln -s ../libola.la ola/.libs/libola.lai
rdlibtool  --tag=CXX   --mode=link g++ -I../include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden  -Werror -Wno-error=deprecated-declarations -g -O2 -std=gnu++11    -o examples/ola_dev_info examples/ola-client.o common/libolacommon.la ola/libola.la common/protocol/libolaproto.la

As can be seen in the rdlibtool command ola/libola.la is linked with common/libolacommon.la a a dependency.

rdlibtool --tag=CXX --mode=link g++ -I../include -I./include -Wall -Wformat -W -fvisibility-inlines-hidden -Werror -Wno-error=deprecated-declarations -Werror -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=sign-compare -g -O2 -std=gnu++11 -version-info 1:1:0 -o ola/libola.la -rpath /usr/local/lib ola/libola_la-AutoStart.lo ola/libola_la-ClientRDMAPIShim.lo ola/libola_la-ClientTypesFactory.lo ola/libola_la-Module.lo ola/libola_la-OlaCallbackClient.lo ola/libola_la-OlaClient.lo ola/libola_la-OlaClientCore.lo ola/libola_la-OlaClientWrapper.lo ola/libola_la-StreamingClient.lo common/libolacommon.la

And yet the linker command doesn't include libolacommon.a as part of the libola.a archive.

ar -crs ola/.libs/libola.a ola/libola_la-AutoStart.o ola/libola_la-ClientRDMAPIShim.o ola/libola_la-ClientTypesFactory.o ola/libola_la-Module.o ola/libola_la-OlaCallbackClient.o ola/libola_la-OlaClient.o ola/libola_la-OlaClientCore.o ola/libola_la-OlaClientWrapper.o ola/libola_la-StreamingClient.o

In the previous issue symbols are being added twice when doing a static build, but now they aren't being included at all...

Fixed as of commit 198205f.
Edited 2 months ago by midipix

Metadata Update from @orbea:
- Issue status updated to: Closed (was: Open)
2 months ago

Login to comment on this ticket.

Metadata
None
None
None
None

Powered by Pagure 5.13.3

SSH Hostkey/Fingerprint | Documentation | About

© Red Hat, Inc. and others.