GNOME Bugzilla – Bug 572532
OpenEmbedded crosscompiling failes due to selection of wrong staging libdir in latest releases of -base, -good, -bad, -ugly
Last modified: 2009-08-10 23:54:02 UTC
Please describe the problem: I used to be able to crosscompile the gstreamer plugin packages using OpenEmbedded and Bitbake for mips32 architecture just like that. Releases gst-plugins-good_0.10.13.bb and gst-plugins-base_0.10.22.bb now require a modification of all the libdir variables in all the .../build/tmp/staging/mipsel-linux/lib/libgst*-0.10.la files to libdir='.../build/tmp/staging/mipsel-linux/lib/' where #libdir='/usr/lib' used to work fine and still select the target-architecture symbols correctly. i haven't tested with bad and ugly 0.10.10 since they are depended on base but i assume the same problem there. Steps to reproduce: in openembedded, create packages for gst-plugins-*, based upon copies of the previous revisions and bitbake ... Actual results: except from openembedded compile log: libtool: link: ccache mipsel-linux-gcc -shared .libs/libgsttag_0.10_la-gstvorbistag.o .libs/libgsttag_0.10_la-gstid3tag.o .libs/libgsttag_0.10_la-tags.o .libs/libgsttag_0.10_la-gsttagdemux.o -Wl,-rpath -Wl,/dream/dm8000/build/tmp/work/gstreamer-0.10.22-r0/gstreamer-0.10.22/gst/.libs -Wl,-rpath -Wl,/dream/dm8000/build/tmp/staging/mipsel-linux/lib/ -Wl,-rpath -Wl,/dream/dm8000/build/tmp/staging/mipsel-linux/lib -Wl,-rpath -Wl,/dream/dm8000/build/tmp/staging/mipsel-linux/lib/ -L/dream/dm8000/build/tmp/work/gstreamer-0.10.22-r0/gstreamer-0.10.22/gst/.libs -L/dream/dm8000/build/tmp/staging/mipsel-linux/lib/.libs -L/dream/dm8000/build/tmp/staging/mipsel-linux/lib /usr/lib/libgstbase-0.10.so /dream/dm8000/build/tmp/work/gstreamer-0.10.22-r0/gstreamer-0.10.22/gst/.libs/libgstreamer-0.10.so /dream/dm8000/build/tmp/staging/mipsel-linux/lib//libgstreamer-0.10.so -lrt /dream/dm8000/build/tmp/staging/mipsel-linux/lib/libgobject-2.0.so /dream/dm8000/build/tmp/staging/mipsel-linux/lib/libgmodule-2.0.so /dream/dm8000/build/tmp/staging/mipsel-linux/lib/libgthread-2.0.so -lpthread /dream/dm8000/build/tmp/staging/mipsel-linux/lib/libxml2.so -ldl /dream/dm8000/build/tmp/staging/mipsel-linux/lib/libz.so -lm /dream/dm8000/build/tmp/staging/mipsel-linux/lib/libglib-2.0.so -Wl,-rpath-link -Wl,/dream/dm8000/build/tmp/staging/mipsel-linux/lib -Wl,-O1 -pthread -pthread -pthread -Wl,-soname -Wl,libgsttag-0.10.so.0 -Wl,-version-script -Wl,.libs/libgsttag-0.10.ver -o .libs/libgsttag-0.10.so.0.16.0 /usr/lib/libgstbase-0.10.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status it uses my amd64 host machine's libs instead of the staging target architecture one's Expected results: make should succeed, like in the previous releases Does this happen every time? yes Other information:
found out some more about the problem. it uses host libtool instead of target-libtool. cf.: diff gst-plugins-base-0.10.21-r0/gst-plugins-base-0.10.21/aclocal.m4 gst-plugins-base-0.10.22-r0/gst-plugins-base-0.10.22/aclocal.m4 [...] 2810c2673 < LIBTOOL='$(SHELL) $(top_builddir)/mipsel-linux-libtool' --- > LIBTOOL='$(SHELL) $(top_builddir)/libtool' now just to find out why...
another finding... not only is mipsel-linux-libtool not used, it is not built at all.
changing the installed= line in all files .../build/tmp/staging/mipsel-linux/lib/libgst*-0.10.la from yes to no worksaround the problem
a workaround is deleting some m4 files for i in libtool ltoptions ltsugar ltversion lt~obsolete; do rm ${S}/common/m4/$i.m4 || /bin/true; done