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
