2 Jun
2015
2 Jun
'15
2:50 p.m.
Hi Folks,
When I build OpenBsc, I find a number of cases where libosmovty isn't in the link, but
is needed by libosmoabis (basically anywhere libosmoabis is linked, but vty isn't)
e.g.
/bin/ld: warning: libosmovty.so.1, needed by /.build/usr/local/lib/libosmoabis.so, not
found (try using -rpath or -rpath-link)
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_node'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element_ve'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out_rate_ctr_group'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_install_default'
I'm not sure why/how I'm seeing this and others apparently aren't, but it
looks legitimate. I've verified the configure script has [correctly] derived build
configfrom the staged pkgconfig:
LIBOSMOABIS_CFLAGS='-I/.build/usr/local/include/ '
LIBOSMOABIS_LIBS='-L/.build/usr/local/lib -losmoabis '
So I wonder if libosmoabis.pc.in should be updated to include vty, a bit like
libosmogb.pc.in i.e.
Signed-off-by: Michael McTernan <Michael.McTernan(a)wavemobile.com>
--- libosmoabis.pc.in (revision 19495)
+++ libosmoabis.pc.in (working copy)
@@ -6,6 +6,6 @@
Name: A-bis Core Library
Description: C Utility Library
Version: @VERSION@
-Libs: -L${libdir} -losmoabis
+Libs: -L${libdir} -losmoabis -losmovty
Cflags: -I${includedir}/
Otherwise every user of libosmoabis has to remember to link with -losmovty as well.
Kind Regards,
Mike
PS: I've stripped the very long full build paths from output - I don't really
build in /.build!
2 Jun
2 Jun
3:59 p.m.
On 02 Jun 2015, at 14:50, Mike McTernan (wavemobile)
<mike.mcternan(a)wavemobile.com> wrote:
Hi Folks,
Hi!
When I build OpenBsc, I find a number of cases where
libosmovty isn’t in the link, but is needed by libosmoabis (basically anywhere libosmoabis
is linked, but vty isn’t) e.g.
/bin/ld: warning: libosmovty.so.1, needed by /.build/usr/local/lib/libosmoabis.so, not
found (try using -rpath or -rpath-link)
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_node’
-Libs: -L${libdir} -losmoabis
+Libs: -L${libdir} -losmoabis -losmovty
When I grew up the rule was link to the libraries whose symbols you are using. In this
case libosmo-abis does use libosmovty symbols and it does link to it. I assume that there
is a NEEDED entry in the elf header of libosmo-abis.
Which system do you compile it on? I think the above is kind of a work-around for another
issue in the system.
holger
4:44 p.m.
Hi Holger,
When I grew up the rule was link to the libraries
whose symbols you are
using. In this case libosmo-abis does use libosmovty symbols and it does link
to it.
Yes, here’s the link line for libosmoabis, showing the link of vty and dependent libs:
/bin/sh ../libtool --tag=CC --mode=link arm-x-linux-gnueabi-gcc -Wall
-I/.build/usr/local/include/ -I/.build/usr/local/include/ -I/.build/usr/local/include/
-D_REENTRANT -DORTP_INET6 -I /.build/usr/local/include -g -O2 -version-info 0:0:0
-o libosmotrau.la -rpath /usr/local/lib libosmotrau_la-osmo_ortp.lo
-L/.build/usr/local/lib -losmocore -L/.build/usr/local/lib -losmogsm
-L/.build/usr/local/lib -losmovty -L/.build/usr/local/lib -lortp -lpthread -lrt
I assume that there is a NEEDED entry in the elf
header of libosmo-abis.
Sure is:
$ arm-x-linux-gnueabi-objdump -x libosmoabis.so | grep NEEDED
NEEDED libosmocore.so.6
NEEDED libosmogsm.so.5
NEEDED libosmovty.so.1
NEEDED libgcc_s.so.1
NEEDED libc.so.6
Which system do you compile it on?
This is cross-compiling for arm, gcc from Sourcery CodeBench Lite 2012.09-104, 4.7.2.
I think the above is kind of a work-around for another
issue in the system.
I cross-compile and install to a stage using DESTDIR at the install step. This means that
at link time the rpath, while correct for the final system, isn't valid (which is
pretty much what the linker is hinting at in the warning). Also from 'man ld':
"The -rpath option is also used when locating shared objects which are needed by
shared objects explicitly included in the link"
So rpath makes it work if building and installing either natively or to a mocked
environment, but we become stuck if staging in a different directory. Passing the library
itself uses different search rules, and so that works.
I guess the other options are to hack with LDFLAGS and LIBS in the build, or set
LD_RUN_PATH in the environment. I'll keep the patch locally for now I think
though...
Kind Regards,
Mike
4:46 p.m.
On 02 Jun 2015, at 16:44, Mike McTernan (wavemobile)
<mike.mcternan(a)wavemobile.com> wrote:
Hi Holger,
Hi!
Which system
do you compile it on?
This is cross-compiling for arm, gcc from Sourcery CodeBench Lite 2012.09-104, 4.7.2.
I think the above is kind of a work-around for
another issue in the system.
I cross-compile and install to a stage using DESTDIR at the install step. This means
that at link time the rpath, while correct for the final system, isn't valid (which is
pretty much what the linker is hinting at in the warning). Also from 'man ld’:
3263
days inactive
3263
days old
3 comments
2 participants
participants (2)
-
Holger Freyther -
Mike McTernan (wavemobile)