On Fri, Feb 25, 2011 at 06:46:58 +0100, Jakub Bogusz wrote: >> I can't compile it properly anyway... at this point x86_64 build tried >> to link against /usr/lib/libstdc++.so: >> http://buildlogs.pld-linux.org/index.php?dist=th&arch=x86_64&ok=0&name=OGLFT&id=46a4776a-6cea-4bb5-a723-efaa66f7388f&action=tail > > You need to trace where "-L/usr/lib" in libtool --mode=link comes from. > Maybe qt setup ("-L$QTDIR/lib" is common bug).
Probably, because rel. 1 without Qt support has been build. As for .la I can repackage it in -static (after reading previous discussion), because it's useless and wrong in devel and _all of them_ are nondeterministic anyway (but it's less probable that most of the -static would be installed on builders), if you want to revive this discussion I got no response for the latter: http://www.mail-archive.com/pld-devel-en@lists.pld-linux.org/msg05937.html http://www.mail-archive.com/pld-devel-en@lists.pld-linux.org/msg05951.html Either BR: *-static for static builds _or better_, do some .la postprocessing to make them more deterministic (like s/-l(.*)/\1.la/ and disabling autorequires for other .la files). I prefer the second solution unless it creates other problems (for example: what if we don't have appropriate .la file, because library is pc-enabled? would it be enough to ship stub .la file instead?). -- Tomasz Pala <go...@pld-linux.org> _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en