dbus-1.2.3-r1 only cross-compiles if we autoreconfigure the thing. Else we get a wrong sys_lib_search_path_spec which in turn leads to wrong linker path specifications to libtool. Patch follows. Reproducible: Always
Created attachment 186359 [details, diff] Fix for dbus ebuild Enforce autoreconf to make dbus cross-compile.
if you're only after updated libtool files, does elibtoolize not work ?
The root of the evil is a malformed aclocal, so I guess elibtoolize won't help here, does it?
Hi Sven - can you do me a favor and see if the 1.2.12 (I think is the version) in my overlay works? (It's in layman) - although presently github is down, so it won't be able to do a checkout - I want to push it into the tree soon, but I need more testing done to it (and this kind of bug is the perfect thing for that) if GitHub isn't back up soon, I will just attach the files here as needed.
Steev, "in my overlay" is somewhat ambigious. :-) Do you mean http://git.overlays.gentoo.org/gitweb/?p=dev/steev.git;a=summary ? If so, then I had to reply: there is no version of dbus... :-)
Ah, no - I meant the one on GitHub which is currently down (it's available in Layman) - I didn't post the url because GitHub is still currently down so it would be pointless :)
aclocal.m4 is autogenerated from other files, so unless those other files are fixed (or in this case it's just a matter of the autogenerated files coming from older/broken versions), then elibtoolize wouldnt matter. besides, that file isnt used at configure time, only when regenerating some autotool files. it all goes into the configure script.
SpanKY, I know that aclocal.m4 is autogenerated, e.g. after a autoreconf, that's why I request it. :-) The truth is I couldn't find the bug in the project itself (sys_lib_search_path_spec is hardcoded to /usr/lib /lib in aclocal.m4), so I assumed it should be a m4 included during autoconf.
Steev, your version fails with exactly the same error. Will attach build.log.
Created attachment 186805 [details] build log
I ran into the very same problem when cross-compiling for "armeb-softfloat-linux-gnu" on "x86_64-pc-linux-gnu". A workaround consists in moving libexpat temporarily out of sight of the libtool script. This works even after configure did run: thus the problem is located in the generated libtool script. I will attach the output obtained from libtool --debug here.
Created attachment 190271 [details] output of libtool --debug dbus-1.2.3/bus: ../libtool --debug --tag=CC --mode=link armeb-softfloat-linux-uclibc-gcc -ffunction-sections -fdata-sections -Os -pipe -rdynamic -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -Wdeclaration-after-statement -fno-common -Wl,--gc-sections -pie -Wl,-z,relro -Wl,-O1 -o dbus-daemon activation.o bus.o config-parser.o config-parser-common.o connection.o desktop-file.o dir-watch-inotify.o dispatch.o driver.o expirelist.o policy.o selinux.o services.o signals.o test.o utils.o config-loader-expat.o main.o -lexpat ../dbus/libdbus-convenience.la
(In reply to comment #12) libtool --version ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18)
dbus 1.3.0 has a eautoreconf; added it for another reason... but i'll drop in a comment in the ebuild so that nobody removes it