Problem compiling OLA
Ronny Nilsson
rln-nard at arbetsmyra.dyndns.org
Mon May 16 15:28:19 CEST 2016
Hi
Yes it's working fine in my device. One non-existing RPATH is still hardcoded
into the olad binary, but it doesn't matter. When a library is missing from
that invalid rpath the dynamic linker just continues with the next path (it
has a long list to try). My olad requires about 2 seconds to start in total.
Here is a copy of my RPi linker conf, check that yours are similar (it's
generated by Nard during the build so it may look different).
root at skeleton-a1fe87b:~> cat /etc/ld.so.conf
/lib
/usr/lib
/usr/local/lib
/opt/lib
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
/lib/modules/4.4.6
/usr/lib/autofs
/usr/lib/gconv
/usr/lib/xtables
root at skeleton-a1fe87b:~>
root at skeleton-a1fe87b:~> ldd /usr/bin/olad
libolaserver.so.0 => /usr/lib/libolaserver.so.0 (0xa6f0b000)
libolacommon.so.0 => /usr/lib/libolacommon.so.0 (0xa6d73000)
libola.so.1 => /usr/lib/libola.so.1 (0xa6d37000)
libdl.so.2 => /lib/libdl.so.2 (0xa6d2c000)
libz.so.1 => /usr/lib/libz.so.1 (0xa6d0c000)
libprotoc.so.9 => /usr/lib/libprotoc.so.9 (0xa6c17000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xa6b32000)
libm.so.6 => /lib/libm.so.6 (0xa6abc000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xa6aa9000)
libpthread.so.0 => /lib/libpthread.so.0 (0xa6a88000)
libc.so.6 => /lib/libc.so.6 (0xa6939000)
libolaartnet.so.0 => /usr/lib/libolaartnet.so.0 (0xa690e000)
liboladummy.so.0 => /usr/lib/liboladummy.so.0 (0xa68fa000)
libolae131.so.0 => /usr/lib/libolae131.so.0 (0xa68be000)
libolaespnet.so.0 => /usr/lib/libolaespnet.so.0 (0xa68a9000)
libolagpio.so.0 => /usr/lib/libolagpio.so.0 (0xa6899000)
libolakarate.so.0 => /usr/lib/libolakarate.so.0 (0xa6886000)
libolakinet.so.0 => /usr/lib/libolakinet.so.0 (0xa6875000)
libolamilinst.so.0 => /usr/lib/libolamilinst.so.0 (0xa6860000)
libolaopendmx.so.0 => /usr/lib/libolaopendmx.so.0 (0xa6857000)
libolaopenpixelcontrol.so.0 => /usr/lib/libolaopenpixelcontrol.so.0
libolapathport.so.0 => /usr/lib/libolapathport.so.0 (0xa6825000)
libolarenard.so.0 => /usr/lib/libolarenard.so.0 (0xa6813000)
libolasandnet.so.0 => /usr/lib/libolasandnet.so.0 (0xa67fd000)
libolashownet.so.0 => /usr/lib/libolashownet.so.0 (0xa67e8000)
libolaspi.so.0 => /usr/lib/libolaspi.so.0 (0xa67d1000)
libolastageprofi.so.0 => /usr/lib/libolastageprofi.so.0 (0xa67bb000)
libolauartdmx.so.0 => /usr/lib/libolauartdmx.so.0 (0xa67a9000)
libolausbdmx.so.0 => /usr/lib/libolausbdmx.so.0 (0xa6748000)
libolausbpro.so.0 => /usr/lib/libolausbpro.so.0 (0xa66ed000)
libolaserverplugininterface.so.0
=> /usr/lib/libolaserverplugininterface.so.0 (0xa6668000)
libmicrohttpd.so.12 => /usr/lib/libmicrohttpd.so.12 (0xa664d000)
librt.so.1 => /lib/librt.so.1 (0xa663d000)
libprotobuf.so.9 => /usr/lib/libprotobuf.so.9 (0xa6536000)
libresolv.so.2 => /lib/libresolv.so.2 (0xa6517000)
/lib/ld-linux.so.3 (0xa6fd6000)
libolaartnetconf.so.0 => /usr/lib/libolaartnetconf.so.0 (0xa64fb000)
libolae131conf.so.0 => /usr/lib/libolae131conf.so.0 (0xa64dc000)
libuuid.so.1 => /usr/lib/libuuid.so.1 (0xa64d1000)
libolagpiocore.so.0 => /usr/lib/libolagpiocore.so.0 (0xa64c3000)
libolaspicore.so.0 => /usr/lib/libolaspicore.so.0 (0xa64a3000)
libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0xa6487000)
libolausbproconf.so.0 => /usr/lib/libolausbproconf.so.0 (0xa646e000)
Can you send me a copy if your SD card image (off list)? Might help me to
reproduce the problem.
/Ronny
------------------------------------------
> Hi Ronny,
>
> Spoke too soon, olad in the target host still tries to load libraries
> not in the regular paths, but non-existant ones and takes a long time to
> search for the next, like this:
>
> #strace olad
> execve("/usr/bin/olad", ["olad"], [/* 15 vars */]) = 0
> brk(0) = 0x15000
> uname({sys="Linux", node="tridmx_raspi_b_rev2-952bbb2c", ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xa6ffc000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
> open("/home/myuser/Projects/RaspberryPi/nard/nard-git/apps/protobuf/protobu
>f-2.6.1/staging/usr/lib/tls/v6l/vfp/libolaserver.so.0", O_RDONLY|O_CLOEXEC
>
> Is it working in your end ? Is this a build host problem ? I'll probably
> update Ubuntu to the latest 16 today, will recompile everything after
> the upgrade.
>
> ii libltdl-dev:amd64 2.4.2-1.11
> amd64 System independent dlopen wrapper for GNU libtool
> ii libltdl7:amd64 2.4.2-1.11
> amd64 System independent dlopen wrapper for GNU libtool
> ii libltdl7:i386 2.4.2-1.11
> i386 System independent dlopen wrapper for GNU libtool
> ii libtool 2.4.2-1.11 all
> Generic library support script
> ii libtool-bin 2.4.2-1.11
> amd64 Generic library support script (libtool binary)
>
> ii autoconf 2.69-8 all automatic
> configure script builder
> ii automake 1:1.15-1ubuntu1 all
> Tool for generating GNU Standards-compliant Makefiles
> ii autotools-dev 20140911.1
> all Update infrastructure for config.{guess,sub} files
>
> On 13-05-2016 10:53, Ronny Nilsson wrote:
> > Hi Rui
> > I gave OLA a spin and you are quite right. OLA cross compiling is
> > effectively broken! Several patches was necessary to make it build...
> > I've included it in my git devel branch now; would you like to check that
> > it actually works? OLA starts fine, but I have no DMX HW for testing.
> > Most of the plugins and examples should be available too.
> >
> > I have only tried Debian 8 as build PC so far. It works if you install
> > these packages: libprotoc-dev and protobuf-compiler. Then you don't need
> > to build everything twice. :)
> >
> > Add these lines to your product recipe:
> > PKGS_APPS += protobuf/protobuf-2.6.1
> > PKGS_APPS += uuid-lib/uuid-lib-1.0.3
> > PKGS_APPS += usb-lib/usb-lib-1.0.20
> > PKGS_APPS += microhttpd-lib/microhttpd-lib-0.9.49
> > PKGS_APPS += openLightingArchitecture/openLightingArchitecture-0.10.1
> >
> > /Ronny
> >
> >
> >
> >
> > ------------------------------------------
> >
> >> Hi Ronny,
> >>
> >> I managed to make it work, I have no idea if this is the right way of
> >> doing it, or if it's just a hack to make it work. By using rlink and
> >> rlink-path I managed to change the order at which the binary will search
> >> for the libraries at startup, by using the following configure on ola:
> >>
> >> cd $(dir $@) && env PKG_CONFIG_DIR=""
> >> PKG_CONFIG_LIBDIR="$(PATH_FS)/usr/lib/pkgconfig:$(PATH_FS)/usr/share/pkg
> >>con fig" PKG_CONFIG_SYSROOT_DIR="$(PATH_FS)" \
> >> CFLAGS="$(CROSS_CFLAGS)" \
> >> CPPFLAGS="$(CROSS_CFLAGS)" \
> >> LDFLAGS="-Wl,-rpath -Wl,/lib -Wl,-rpath -Wl,/usr/lib
> >> -Wl,-rpath-link -Wl,/lib -Wl,-rpath-link -Wl,/usr/lib -L/lib -L/usr/lib"
> >> \ PKG_CONFIG="/usr/bin/pkg-config" \
> >> ./configure \
> >> ac_cv_func_malloc_0_nonnull=yes
> >> ac_cv_func_realloc_0_nonnull=yes \
> >> libprotobuf_CFLAGS="-I$(PATH_FS)/usr/include
> >> -L$(PATH_FS)/usr/lib -Wl,-rpath-link,$(PATH_FS)/usr/lib" \
> >> libprotobuf_LIBS="-L$(PATH_FS)/usr/lib -lprotobuf
> >> -lprotoc" \
> >> base_uuid_CFLAGS="-I$(PATH_FS)/usr/include
> >> -L$(PATH_FS)/usr/lib -Wl,-rpath-link,$(PATH_FS)/usr/lib" \
> >> base_uuid_LIBS="-L$(PATH_FS)/usr/lib -luuid" \
> >> --prefix=/usr \
> >> --host=$(CROSS_TUPLE) \
> >> --target=$(CROSS_TUPLE) \
> >> --disable-dependency-tracking \
> >> --without-dns-sd \
> >> --with-protoc=$(PATH_APPS)/protobuf/native/src/protoc \
> >> --with-ola-protoc-plugin=$(PATH_APPS)/ola/native/protoc/ola_protoc_plugi
> >>n \ --disable-unittests \
> >> --disable-examples \
> >> --disable-rdm-tests \
> >> --disable-doxygen-doc \
> >> --disable-gcov \
> >> --disable-tcmalloc \
> >> --disable-root-check \
> >> --disable-java-libs \
> >> --disable-python-libs \
> >> --disable-fatal-warnings \
> >> --disable-all-plugins
> >>
> >> Notice LDFLAGS, I added /lib and then /usr/lib, this way all libs are
> >> found and it's working properly on the target system.
> >>
> >> Besides this problem, there seems to be a bug in libtool when cross
> >> compiling you might encounter on your tests, that the package libs won't
> >> be found, for that, a hack is necessary, one needs to substitute all
> >> instances of link_all_deplibs=(yes|no) to link_all_deplibs=unknown in
> >> config/libtool.m4
> >>
> >> Here is the short version of the minimum requirements to be able to
> >> cross compile OLA
> >>
> >> - build uuid (any works, I'm using util-linux)
> >> - build protobuf
> >> To build protobuf one needs to build 2 versions, one of them needs
> >> to be native to the host system since binaries are compiled and used
> >> while building itself, then, the second version is indeed the cross
> >> compiled one while passing the --with-protoc=PATH_TO_NATIVE/src/protoc
> >> I'm also using protobuf 2.5.0 since newer versions won't compile and
> >> I haven't bothered much finding out why yet.
> >> - build ola, 2 versions also, one native and the cross compiled one. The
> >> native is needed because of a protobuf plugin used by the protoc binary,
> >> needs to be compiled in the host machine. I do this with the following
> >> configure:
> >>
> >> if [ ! -e native/protoc/ola_protoc_plugin ]; then \
> >> cd native && env CFLAGS="" CPPFLAGS="" LDFLAGS=""
> >> PKG_CONFIG="/usr/bin/pkg-config" \
> >> ./configure \
> >> --disable-all-plugins \
> >> --disable-osc \
> >> --disable-uart \
> >> --disable-libusb \
> >> --disable-libftdi \
> >> --disable-http \
> >> --disable-examples \
> >> --disable-unittests \
> >> --disable-doxygen-html \
> >> --disable-doxygen-doc \
> >> --without-dns-sd \
> >> && $(MAKE) -j "$(CPUS)" protoc/ola_protoc_plugin; fi
> >>
> >> Just disable everything, and only build the ola_protoc_plugin. Then
> >> I proceed to build the cross compile version of OLA with the earlier
> >> configure.
> >>
> >> I'm tidying up all the build process, for everything (including OLA
> >> plugins and such) to have a clean install of the whole system, and when
> >> I do I'll build a patch against nard git and will send if you're
> >> interested.
> >>
> >> For now, I'll move forward in the other tasks I have planned to do (some
> >> command line tools to manage ola and the OS network with a few buttons
> >> and an LCD to have a standalone system without the need of remote ssh
> >> management or web and a few other utilities since I managed to have OLA
> >> for now working, but I'll definitely investigate further about this
> >> rlink/rlink-path hack or fix or whatever.
> >>
> >> If you do give it a whirl and want me to, I can package my current apps
> >> Makefiles and attach them so you can have a starting point.
> >>
> >> Best regards.
> >> Rui Barreiros
> >>
> >> On 05-05-2016 19:32, Ronny Nilsson wrote:
> >>> Hi Rui
> >>> This is looks like a tough one! I don't blame you for having
> >>> problems... I'll try to find some time next week to help.
> >>> /Ronny
> >>>
> >>>
> >>>
> >>> -----------------------------------------
> >>>
> >>>> Hi,
> >>>>
> >>>> I've been trying to compile OLA (https://www.openlighting.org) but
> >>>> been having so many problems I'm melting my brains out !!
> >>>>
> >>>> To build OLA without any plugins, and all superfluous stuff disabled
> >>>> (doc, examples, etc) requires protobuf and uuid, I managed
> >>>> successfully to build and install this libraries (uuid is provided by
> >>>> util-linux), I just make a plain DESTDIR=$(PATH_FS) make install for
> >>>> uuid and protobuf.
> >>>>
> >>>> OLA relies on either pkg-config or env variables to find protobuf and
> >>>> uuid, I tried both and the problem I have happens on any.
> >>>>
> >>>> My problem is, OLA binaries have the lib path hardcoded and when I run
> >>>> them on the raspberry pi, it just hangs forever, an strace reveals:
> >>>>
> >>>> root at tridmx_raspi_b_rev2-952bbb2c:~> strace olad
> >>>> execve("/usr/bin/olad", ["olad"], [/* 15 vars */]) = 0
> >>>> brk(0) = 0x15000
> >>>> uname({sys="Linux", node="tridmx_raspi_b_rev2-952bbb2c", ...}) = 0
> >>>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> >>>> 0) = 0xa6ffc000
> >>>> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> >>>> directory)
> >>>> open("/home/rbarreiros/Projectos/RaspberryPi/nard/nard-git/intermediat
> >>>>e/ fs/ usr/lib/tls/v6l/vfp/libolaserver.so.0", O_RDONLY|O_CLOEXEC) = -1
> >>>> ELOOP (Too many levels of symbolic links)
> >>>> stat64("/home/rbarreiros/Projectos/RaspberryPi/nard/nard-git/intermedi
> >>>>at e/f s/usr/lib/tls/v6l/vfp",
> >>>>
> >>>> Everytime an open/stat call is made, it takes a long long time, until
> >>>> it receives the ELOOP error and attempts another path to try and open
> >>>> libolaserver.so.0
> >>>>
> >>>>
> >>>> Here is the configure/build section for ola Makefile
> >>>>
> >>>> To properly build ola for another system, one needs to build
> >>>> ola_protoc_plugin natively first, as it's used by the protoc (which
> >>>> needs to be built natively first also) to parse from protobuf message
> >>>> files during build, then the cross compilation is done.
> >>>>
> >>>> # Need to build a native ola-protoc-plugin first
> >>>> if [ ! -e native/protoc/ola_protoc_plugin ]; then \
> >>>> cd native && env CFLAGS="" CPPFLAGS="" LDFLAGS=""
> >>>> PKG_CONFIG="/usr/bin/pkg-config" \
> >>>> ./configure \
> >>>> --disable-all-plugins \
> >>>> --disable-osc \
> >>>> --disable-uart \
> >>>> --disable-libusb \
> >>>> --disable-libftdi \
> >>>> --disable-http \
> >>>> --disable-examples \
> >>>> --disable-unittests \
> >>>> --disable-doxygen-html \
> >>>> --disable-doxygen-doc \
> >>>> --without-dns-sd \
> >>>> && $(MAKE) -j "$(CPUS)" protoc/ola_protoc_plugin;
> >>>> fi
> >>>>
> >>>> cd $(dir $@) && env PKG_CONFIG_DIR=""
> >>>> PKG_CONFIG_LIBDIR="$(PATH_FS)/usr/lib/pkgconfig:$(PATH_FS)/usr/share/p
> >>>>kg con fig" PKG_CONFIG_SYSROOT_DIR="$(PATH_FS)" \
> >>>> CFLAGS="$(CROSS_CFLAGS)" \
> >>>> CPPFLAGS="$(CROSS_CFLAGS)" \
> >>>> LDFLAGS="-Wl,-rpath -Wl,/usr/lib -Wl,-rpath-link
> >>>> -Wl,$(PATH_FS)/usr/lib -L$(PATH_FS)/lib -L$(PATH_FS)/usr/lib" \
> >>>> PKG_CONFIG="/usr/bin/pkg-config" \
> >>>> ./configure \
> >>>> ac_cv_func_malloc_0_nonnull=yes
> >>>> ac_cv_func_realloc_0_nonnull=yes \
> >>>> libprotobuf_CFLAGS="-I$(PATH_FS)/usr/include
> >>>> -L$(PATH_FS)/usr/lib -Wl,-rpath-link,$(PATH_FS)/usr/lib" \
> >>>> libprotobuf_LIBS="-L$(PATH_FS)/usr/lib -lprotobuf
> >>>> -lprotoc" \
> >>>> base_uuid_CFLAGS="-I$(PATH_FS)/usr/include
> >>>> -L$(PATH_FS)/usr/lib -Wl,-rpath-link,$(PATH_FS)/usr/lib" \
> >>>> base_uuid_LIBS="-L$(PATH_FS)/usr/lib -luuid" \
> >>>> --prefix=/usr \
> >>>> --host=$(CROSS_TUPLE) \
> >>>> --target=$(CROSS_TUPLE) \
> >>>> --disable-dependency-tracking \
> >>>> --without-dns-sd \
> >>>> --with-protoc=$(PATH_APPS)/protobuf/native/src/protoc \
> >>>> --with-ola-protoc-plugin=$(PATH_APPS)/ola/native/protoc/ola_protoc_plu
> >>>>gi n \ --disable-unittests \
> >>>> --disable-examples \
> >>>> --disable-rdm-tests \
> >>>> --disable-doxygen-doc \
> >>>> --disable-gcov \
> >>>> --disable-tcmalloc \
> >>>> --disable-root-check \
> >>>> --disable-java-libs \
> >>>> --disable-python-libs \
> >>>> --disable-fatal-warnings \
> >>>> --disable-all-plugins
> >>>> $(MAKE) -C "$(PKG_VER)" -j $(CPUS)
> >>>>
> >>>> Worthy of note, I couldn't finish OLA compilation because I kept
> >>>> getting an error where libtool couldn't find it's libraries (OLA
> >>>> libraries) and suggested using rpath or rpath-link, I managed to fix
> >>>> this issue by implementing a fix found here
> >>>> http://bugs.lttng.org/issues/321 in which the configure script goes
> >>>> through all occurrences of link_all_deplibs in config/libtool.m4 and
> >>>> replace all 'no|yes' to unknown.
> >>>>
> >>>> Does anyone have any idea what I'm doing wrong ? or where the bug is ?
> >>>>
> >>>> Best regards.
More information about the Nard
mailing list