On Mon, 2008-10-20 at 08:38 +1100, Erik de Castro Lopo wrote: > Bernd Petrovitsch wrote: > > > Just that I'm not sure I was clear enough: When mentioned > > "cross-compile", I meant: using pkg-config running on the build host > > (because some libs and apps use it) but the compiled libs and apps run > > on the target system. > > So because this runs on the host, as long as it does the CorrectThing (tm) > it really doesn't matter whether it is a binary called > -pkg-config or is a shell script with the same name that > uses the native pkg-config to do the right thing. ACK, I don't care if it's a binary or a shell (or perl or ...) script and if it's uses the native pkg-config. But it should be robust enough (or at least as robust as possible) that it breaks immediately in obvious ways if package maintainers do - ahemm - "creative" stuff with make, autotools, or whatever. The problem is that - at least for cross-compiling - there are enough packages out there that needs working around some toolchain limitations (and reading the generated "configure" shell script is nothing special. Classical problems are "can't find $FUNC" - which is clearly here - and the reason is a new warning with an somewhat old cross-gcc. And updating gcc is usually not really an option - as opposed to killing some -W option - at the lower end of the food chain). > > The special problem is (or was - it was > 1 year ago with > > pkg-config-0.21 that seriously had to make that), > > Version 0.22 was released in June 2007. Sorry, but 0.21 was most recent in February 2007. If the below works with 0.22, sorry for the effort. > > And the problem was *not* "$APP uses $LIB using pkg-config" but it was > > "$APP uses $LIB1 which uses $LIB2 all using pkg-config" because $LIB2 > > was indirectly linked/pulled in by $LIB1 and the compile-time directory > > of $LIB2 ended up in $APP. And the build-time directory structure does > > not exist at run-time (and there is no sane way to get these two to > > match). > > Are you using the full autotools stack for all these apps and libs? Ie > autoconf, automake, libtool and pkg-config? Basically I use what the package supplies/needs. In the example below: yes. > If so, please supply a concrete example of a set of $APP, $LIB1 and $LIB2 > so this can be independantly tested. Its not that I don't believe you > but more that if noone supplies a concrete example this will not get > fixed. Yup, I can fully understand that;-) Here we go: App: lighttpd (or any other using gthread but not explicitly glib) Lib1: gthread ---- snip ---- {60}cat ../../dev-install/lib/pkgconfig/gthread-2.0.pc prefix= exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: GThread Description: Thread support for GLib Requires: glib-2.0 Version: 2.12.9 Libs: -L${libdir} -lgthread-2.0 -pthread -lrt Cflags: -pthread ---- snip ---- Lib2: glib ---- snip ---- {62}cat ../../dev-install/lib/pkgconfig/glib-2.0.pc prefix= exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include glib_genmarshal=glib-genmarshal gobject_query=gobject-query glib_mkenums=glib-mkenums Name: GLib Description: C Utility Library Version: 2.12.9 Libs: -L${libdir} -lglib-2.0 Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include ---- snip ---- All libs and apps are (build-time) installed with DESTDIR=../../dev-install/ (as one needs the various header files etc. during build). When autotools+libtool+pkg-config calculate the dependency to glib, the explicit build-time path to libglib-2.0.so ends up in the lighttpd binary. Please note that there is no explicit path information to libgthread-2.0.so generated. The fix (in some Makefile) was ---- snip ---- perl -w -i -p -e 's|^\s*prefix=.*|prefix=../../dev-install|;' ../../dev-install/lib/pkgconfig/g{lib,thread}-2.0.pc ---- snip ---- to have an appropriate environment variable in place. And a similar line for the .la files from libtool: ---- snip ---- perl -w -i -p -e "\$$_= \"libdir='../../dev-install/lib'\\n\" if (/^libdir=/); s| /lib(/lib[\w.-]+\.la)| ../../dev-install/lib\$$1|g if (/^dependency_libs=/);" ../../dev-install/lib/g{lib,thread}-2.0.la ---- snip ---- [ It is from a Makefile - thus the quoting. And the "../../dev-install" is actually an absolute path - but that doesn't really matter here. ] Yes, gthread is part of glib. But it has it's own .pc file so it is a separate lib. Now that I prepared that mail: Basically only clean support of a/the DESTDIR support (similar to autotools) seems to be missing. [...] > > JftSoC: More than enough libs and apps also require to compile programs > > transparently as part of the build process. So the simple "just change > > PATH to all of the cross-tools" and similar is also not possible. > > Thats is a problem that needs to be addressed with the authors of that > software. It is not a problem that the developers of the autotools can > help you with. Of course (and I don't want to push my problems in all directions until they vanish for me creating the multiple amount of burden everywhere else - I just can't tell where the root cause is as I don't know internals, interfaces/APIs and relation of pkg-config, the various parts of autotools and libtool). And I can live with individual workarounds in some high-level Makefile's building 20+ packages. However, if there are more candidate packages to choose (e.g. for an HTTP server), those without workarounds are clearly preferred - most devices don't need any fancy stuff from an HTTP server so one can choose the least problematic when it comes to cross-compiling. However, if some package maintainer decides that a build tool should be written in (e.g.) C (and not some script language like perl), it is so and the users of that package (read: /me) must live with it. But I'd appreciate to see any problem/inconsistency as soon and obvious as possible. Bernd PS: Please understand the "I"s above as "IMHO all cross-compiling packagers". -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services