[OpenWrt-Devel] Cross Libtool

Discussion:

Drasko DRASKOVIC

2012-11-13 23:38:08 UTC

Hi all,
Trying to cross compile libdespotify, I have run into problem with libtool :

libtool --tag=CC --verbose --mode=link
mipsel-openwrt-linux-uclibc-gcc -o libdespotify.la -rpath /usr/lib
-rpath-link /home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib
-lz -lvorbisfile -lcrypto -lresolv -lpthread aes.lo auth.lo buf.lo
cache.lo channel.lo commands.lo dns.lo ezxml.lo handlers.lo
keyexchange.lo packet.lo puzzle.lo session.lo shn.lo sndqueue.lo
util.lo network.lo despotify.lo sha1.lo hmac.lo xml.lo
OpenWrt-libtool: link: gcc -shared -fPIC -DPIC .libs/aes.o
.libs/auth.o .libs/buf.o .libs/cache.o .libs/channel.o
.libs/commands.o .libs/dns.o .libs/ezxml.o .libs/handlers.o
.libs/keyexchange.o .libs/packet.o .libs/puzzle.o .libs/session.o
.libs/shn.o .libs/sndqueue.o .libs/util.o .libs/network.o
.libs/despotify.o .libs/sha1.o .libs/hmac.o .libs/xml.o
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib
-lz -lvorbisfile -lcrypto -lresolv -lpthread -Wl,-soname
-Wl,libdespotify.so.0 -o .libs/libdespotify.so.0.0.0
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
.libs/aes.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[3]: *** [libdespotify.la] Error 1

Instead of cross-compiler, libtool calls native gcc in the link mode
(in the compile mode everything OK, though).

This problem is described here :
http://www.metastatic.org/text/libtool.html

I have two questions at this point :
1) I sew that OpenWRT buildsystem uses staging_dir/host/bin/libtool.
If this (host) libtool is normally used for building packages and not
cross compiled libtool, did I do something wrong in my Makefile?

2) If some other, cross-compiled libtool should be used, where can I
find it? I do not see it in the toolchain directory. However, I can
see many different libtools, si I was wondering why we need so many
and how are they different :

***@Marx:~/carambola/carambola$ find . -name libtool
./tools/libtool
./build_dir/linux-ramips_rt305x/opkg-618/libtool
./build_dir/linux-ramips_rt305x/iptables-1.4.10/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libao-1.1.0/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libvorbis-1.2.3/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/liblo-0.26/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/alsa-lib-1.0.24.1/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libogg-1.1.4/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/json-c-0.9/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/udev-173/libtool
./build_dir/host/gmp-5.0.5/libtool
./build_dir/host/libtool-2.4/libtool
./build_dir/host/pkg-config-0.25/glib-1.2.10/libtool
./build_dir/host/pkg-config-0.25/libtool
./build_dir/host/opkg-618/libtool
./build_dir/host/mpc-0.9/libtool
./build_dir/host/xz-5.0.3/libtool
./build_dir/host/mpfr-3.0.0/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/opcodes/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/ld/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/gas/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/binutils/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/bfd/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/gprof/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/lto-plugin/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/zlib/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/mipsel-openwrt-linux-uclibc/libstdc++-v3/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/mipsel-openwrt-linux-uclibc/libquadmath/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gdb-linaro-7.2-2011.03-0/opcodes/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gdb-linaro-7.2-2011.03-0/bfd/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-initial/lto-plugin/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-initial/zlib/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-minimal/lto-plugin/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-minimal/zlib/libtool
./package/libtool
./staging_dir/host/bin/libtool
./staging_dir/host/share/libtool
***@Marx:~/carambola/carambola$

BR,
Drasko

Florian Fainelli

2012-11-14 09:22:07 UTC

Permalink

Hello Drasko,

Post by Drasko DRASKOVIC
Hi all,
libtool --tag=CC --verbose --mode=link
mipsel-openwrt-linux-uclibc-gcc -o libdespotify.la -rpath /usr/lib
-rpath-link /home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib
-lz -lvorbisfile -lcrypto -lresolv -lpthread aes.lo auth.lo buf.lo
cache.lo channel.lo commands.lo dns.lo ezxml.lo handlers.lo
keyexchange.lo packet.lo puzzle.lo session.lo shn.lo sndqueue.lo
util.lo network.lo despotify.lo sha1.lo hmac.lo xml.lo
OpenWrt-libtool: link: gcc -shared -fPIC -DPIC .libs/aes.o
.libs/auth.o .libs/buf.o .libs/cache.o .libs/channel.o
.libs/commands.o .libs/dns.o .libs/ezxml.o .libs/handlers.o
.libs/keyexchange.o .libs/packet.o .libs/puzzle.o .libs/session.o
.libs/shn.o .libs/sndqueue.o .libs/util.o .libs/network.o
.libs/despotify.o .libs/sha1.o .libs/hmac.o .libs/xml.o
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib
-L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib
-lz -lvorbisfile -lcrypto -lresolv -lpthread -Wl,-soname
-Wl,libdespotify.so.0 -o .libs/libdespotify.so.0.0.0
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
/usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8)
.libs/aes.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[3]: *** [libdespotify.la] Error 1
Instead of cross-compiler, libtool calls native gcc in the link mode
(in the compile mode everything OK, though).

I see several issues with this log excerpt:
- the first libtool link command uses /usr/lib as a host path (second line)
this needs fixing
- the second libtool command does not use the cross-linker, and for that I
have no idea yet

Post by Drasko DRASKOVIC
http://www.metastatic.org/text/libtool.html
1) I sew that OpenWRT buildsystem uses staging_dir/host/bin/libtool.
If this (host) libtool is normally used for building packages and not
cross compiled libtool, did I do something wrong in my Makefile?

The compiled libtool resides in host because it is actually compiled for the
host system, there is no other libtool executable in the build system besides
those copies provided by other packages we build.

Post by Drasko DRASKOVIC
2) If some other, cross-compiled libtool should be used, where can I
find it? I do not see it in the toolchain directory. However, I can
see many different libtools, si I was wondering why we need so many
./tools/libtool
./build_dir/linux-ramips_rt305x/opkg-618/libtool
./build_dir/linux-ramips_rt305x/iptables-1.4.10/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libao-1.1.0/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libvorbis-1.2.3/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/liblo-0.26/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/alsa-lib-1.0.24.1/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libogg-1.1.4/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/json-c-0.9/libtool
./build_dir/target-mipsel_r2_uClibc-0.9.33.2/udev-173/libtool
./build_dir/host/gmp-5.0.5/libtool
./build_dir/host/libtool-2.4/libtool
./build_dir/host/pkg-config-0.25/glib-1.2.10/libtool
./build_dir/host/pkg-config-0.25/libtool
./build_dir/host/opkg-618/libtool
./build_dir/host/mpc-0.9/libtool
./build_dir/host/xz-5.0.3/libtool
./build_dir/host/mpfr-3.0.0/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/opcodes/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/ld/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/gas/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/binutils/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/bfd/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/gprof/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/lto-plugin/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/zlib/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/mipsel-openwrt-linux-uclibc/libstdc++-v3/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/mipsel-openwrt-linux-uclibc/libquadmath/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gdb-linaro-7.2-2011.03-0/opcodes/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gdb-linaro-7.2-2011.03-0/bfd/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-initial/lto-plugin/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-initial/zlib/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-minimal/lto-plugin/libtool
./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-minimal/zlib/libtool
./package/libtool
./staging_dir/host/bin/libtool
./staging_dir/host/share/libtool
BR,
Drasko
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Drasko DRASKOVIC

2012-11-14 10:24:10 UTC

Permalink

Hi Florian,

Post by Florian Fainelli
Hello Drasko,

- the first libtool link command uses /usr/lib as a host path (second line)
this needs fixing

I have passes -rpath as /usr/lib, as this should be the place where
this library will reside in the system. However, -rpath-link points to
staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib, where other
libraries needed for linking should be found.

If this is not the correct procedure, where -rpath should point to?
And -rpath-link?

Post by Florian Fainelli
- the second libtool command does not use the cross-linker, and for that I
have no idea yet

It does not, and it is related to the bug (or wrong params) in the
libtool described here :
http://www.metastatic.org/text/libtool.html

--tag=CC can be passed to libtool, and then it uses
mipsel-openwrt-linux-uclibc-gcc for compilatin, which is correct.
However, in the link stage with same --tag=CC passed, it switches to
the native gcc which is wrong and provokes errors.

Solution here is either to correct libtool or use cross libtool, I
think, but I am not quite sure. It sounds strange to me that I am the
first person in the world who cross compiles libraries with libtool on
OpenWRT...

Post by Florian Fainelli

So, if I undersand correctly, each package provides it's own libtool ?
Maybe some of these libtools are cross-compiled during package
cross-compilation.

However, it would be not a good practice to use libtool of some other package...

Is it the mandatory for every package that should use libtool to
provide it's own libtool ?

BR,
Drasko

Florian Fainelli

2012-11-14 10:36:02 UTC

Permalink

Post by Drasko DRASKOVIC
Hi Florian,

Post by Florian Fainelli
Hello Drasko,

- the first libtool link command uses /usr/lib as a host path (second line)
this needs fixing

Ok, I did not understand you added that.

Post by Drasko DRASKOVIC
If this is not the correct procedure, where -rpath should point to?
And -rpath-link?

Post by Florian Fainelli
- the second libtool command does not use the cross-linker, and for that I
have no idea yet

It does not, and it is related to the bug (or wrong params) in the
http://www.metastatic.org/text/libtool.html
--tag=CC can be passed to libtool, and then it uses
mipsel-openwrt-linux-uclibc-gcc for compilatin, which is correct.
However, in the link stage with same --tag=CC passed, it switches to
the native gcc which is wrong and provokes errors.

Should not you use --tag=LD then? I agree that it should work anyway.

Post by Drasko DRASKOVIC
Solution here is either to correct libtool or use cross libtool, I
think, but I am not quite sure. It sounds strange to me that I am the
first person in the world who cross compiles libraries with libtool on
OpenWRT...

There is no such thing as a cross-libtool, as it does not make sense, a cross
libtool would mean a libtool that gets compiled for your target platform, but
executed on the build platform? That does not fly.

Post by Drasko DRASKOVIC

Post by Florian Fainelli

So, if I undersand correctly, each package provides it's own libtool ?

Most do, which is the reason why we build our own copy and instruct the OpenWrt
build system to use our own libtool copy to make sure everything goes smoothly.

Post by Drasko DRASKOVIC
Maybe some of these libtools are cross-compiled during package
cross-compilation.
However, it would be not a good practice to use libtool of some other package...
Is it the mandatory for every package that should use libtool to
provide it's own libtool ?

No, but packages that do provide a libtool should be built by OpenWrt with
PKG_LIBTOOL_PATHS and PKG_FIXUP accordingly.
--
Florian

Drasko DRASKOVIC

2012-11-14 11:14:30 UTC

Permalink

Post by Florian Fainelli

Post by Drasko DRASKOVIC

Post by Florian Fainelli
- the second libtool command does not use the cross-linker, and for that I
have no idea yet

Should not you use --tag=LD then? I agree that it should work anyway.

No, this tag is not recognized by libtool (my idea exactly,
unfortunately it ignores it as an unknown tag).

Post by Florian Fainelli

Well, cross-libtool sort-of, this is what I wanted to say. libtool is
just a shell script (10k lines long horror), but it can be configured

Post by Florian Fainelli
./configure --prefix=/opt/Toolchain --host=target --program-prefix=target-

Please refer to the link http://www.metastatic.org/text/libtool.html,
section "The wrong-gcc problem".

I do not know what this configure does, but I guess it changes some
internal variables inside libtool, so it changes the way it constructs
it's compilation command.

Libtool provided by OpenWRT is the one for the host.
Libtools provided by packages are in my opinion configured and
"make"-d during the package cross-compilation, thus they work well
with the target code.

What OpenWRT is missing is cross-compiled libtool that should be
somewhere in the toolchain (binutils?) directory, that I can use,
instead of cross-making libtool for every package.

even worse, libtool has to be pached in order to change it's internal
"libdir" variable (link http://www.metastatic.org/text/libtool.html,
first section). This is done in OpenWRT by libtool patch for the host
libtool, but is this done for every libtool provided with the package?
I seriously doubt. Maybe this patching could be configured with
PKG_FIXUP:=autoreconf, as suggested before, but this is another
problem.

Primary problem for now is cross-compiler call, and does every package
has to provide it's own libtool.

BR,
Drasko

Drasko DRASKOVIC

2012-11-14 22:10:45 UTC

Permalink

Post by Florian Fainelli
No, but packages that do provide a libtool should be built by OpenWrt with
PKG_LIBTOOL_PATHS and PKG_FIXUP accordingly.

libdespotify I am trying to compile does not provide it's libtoo. I am
using OpenWRTs tool, which calls cross compiler in "compile" mode, but
in the link mode it fails back to native gcc, which is wrong.

BR,
Drasko

Jo-Philipp Wich

2012-11-14 10:34:47 UTC

Permalink

Hi,

in most cases it is enough to specify

PKG_FIXUP:=autoreconf

in the OpenWrt Makefile. This will regenerate configure scripts,
Makefiles and embedded libtool copies with patched variants.

~ Jow

Drasko DRASKOVIC

2012-11-14 10:56:24 UTC

Permalink

Hi Jow,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
in most cases it is enough to specify
PKG_FIXUP:=autoreconf
in the OpenWrt Makefile. This will regenerate configure scripts,
Makefiles and embedded libtool copies with patched variants.

I did not provide embedded libtool. I thought that one present in the
OpenWRT can be used, passing --tag=CC as a parameter.

It turns out that it is buggy on the link stage (as I described).

Does this means that every package __HAS__ to provide embedded libtool ?

BR,
Drasko

Jo-Philipp Wich

2012-11-14 11:04:53 UTC

Permalink

Post by Drasko DRASKOVIC
It turns out that it is buggy on the link stage (as I described).

It works for any other package so it is unlikely to be "buggy on the
link stage". It is most likely improperly called by the Makefile.

Post by Drasko DRASKOVIC
Does this means that every package __HAS__ to provide embedded
libtool ?

No.

~ Jow

Jo-Philipp Wich

2012-11-14 11:08:37 UTC

Permalink

Post by Jo-Philipp Wich
It works for any other package so it is unlikely to be "buggy on
the link stage". It is most likely improperly called by the
Makefile.

And indeed, line 11 of despotify's Makefile says:

LD = $(CC)

That is the most likely culprit.

~ Jow

Drasko DRASKOVIC

2012-11-14 22:09:12 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Jo-Philipp Wich
It works for any other package so it is unlikely to be "buggy on
the link stage". It is most likely improperly called by the
Makefile.

LD = $(CC)
That is the most likely culprit.

I commented out this line. Still the same problem : during the compile
phase libtool calls cross-compiler. During link phase it calls native
host gcc.

BR,
Drasko

Jo-Philipp Wich

2012-11-15 12:07:18 UTC

Permalink

Provide your current OpenWrt Makefile. I still believe you're using
libtool wrong.

~ Jow

Florian Fainelli

2012-11-14 11:04:28 UTC

Permalink

Post by Drasko DRASKOVIC
Hi Jow,

I did not provide embedded libtool. I thought that one present in the
OpenWRT can be used, passing --tag=CC as a parameter.
It turns out that it is buggy on the link stage (as I described).
Does this means that every package __HAS__ to provide embedded libtool ?

No, as I explained it in my email, you just need to tell the OpenWrt makefile
specific to your package that you should use the OpenWrt-provided libtool and
not the one shipped with your package by default.
--
Florian