Re: [OpenWrt-Devel] Cross Libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Provide your current OpenWrt Makefile. I still believe you're using libtool wrong. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCk2vIACgkQdputYINPTPPXygCfWaaGuwXngeiJ6IbydvkwMAmZ 79kAni+M2VydxCPm26EMmXHeqDNwhC5S =r1OO -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
Hello Drasko, On Wednesday 14 November 2012 00:38:08 Drasko DRASKOVIC wrote: 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). 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 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? 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. 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 : drasko@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
Re: [OpenWrt-Devel] Cross Libtool
Hi Florian, On Wed, Nov 14, 2012 at 10:22 AM, Florian Fainelli flor...@openwrt.org wrote: Hello Drasko, On Wednesday 14 November 2012 00:38:08 Drasko DRASKOVIC wrote: 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). 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 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? - 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... 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? 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. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
-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. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCjc8QACgkQdputYINPTPOE5gCfQUTbBZR/FCQGUZOFRnRVUSBl va4AnitEOcE+pzhBVwv9hAblGD4Xqzxp =sWm3 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wednesday 14 November 2012 11:24:10 Drasko DRASKOVIC wrote: Hi Florian, On Wed, Nov 14, 2012 at 10:22 AM, Florian Fainelli flor...@openwrt.org wrote: Hello Drasko, On Wednesday 14 November 2012 00:38:08 Drasko DRASKOVIC wrote: 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). 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 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. Ok, I did not understand you added that. If this is not the correct procedure, where -rpath should point to? And -rpath-link? - 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. Should not you use --tag=LD then? I agree that it should work anyway. 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. 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? 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. 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. 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
Re: [OpenWrt-Devel] Cross Libtool
Hi Jow, On Wed, Nov 14, 2012 at 11:34 AM, Jo-Philipp Wich x...@subsignal.org wrote: -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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCje7UACgkQdputYINPTPN5YgCfbomEFrqSvvs0DWiisRb90jkB MwMAoI7fBoaLnf7+eCpdWSjeM1PcUIiC =ZbM9 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wed, Nov 14, 2012 at 11:36 AM, Florian Fainelli flor...@openwrt.org wrote: On Wednesday 14 November 2012 11:24:10 Drasko DRASKOVIC wrote: - 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. 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). 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. 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 for the target like this : ./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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wed, Nov 14, 2012 at 12:08 PM, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wed, Nov 14, 2012 at 11:36 AM, Florian Fainelli flor...@openwrt.org wrote: 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
