Problem compiling OLA
Rui Barreiros
rbarreiros at gmail.com
Tue May 17 12:26:25 CEST 2016
As I suspected, the problem persists, using latest Ubuntu as building
host, olad still tries to search for libs on the wrong paths when
starting on the target host. Doesn't seem to be a platform problem :(
On to other triage methods !
Best regards,
Rui Barreiros
On 16-05-2016 12:49, Rui Barreiros wrote:
> 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/protobuf-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/pkgcon
>>>
>>> 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_plugin
>>> \
>>> --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/intermediate/
>>>>>
>>>>> 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/intermediat
>>>>>
>>>>> 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/pkg
>>>>>
>>>>> 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_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
>>>>> $(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.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2109 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.arbetsmyra.dyndns.org/pipermail/nard/attachments/20160517/0b188cf9/attachment.bin
More information about the Nard
mailing list