Created attachment 279509 [details] emerge --info media-libs/lensfun is installing itself into /usr/lib64 on my 32-bit x86 system. digikam then of course fails to find it for linking. I don't have any logs since emerge is successful, so please let me know what other info might be needed.
Please emerge it with FEATURES=keeptemp and attach the (not deleted) logfile :)
Created attachment 279555 [details] build.log Here it is... I suspect it's seeing the 64-bit kernel and assuming for some reason that the OS/userland is the same :/
Yeah, sounds reasonable.
Created attachment 282529 [details] media-libs/lensfun-0.2.5-r2.ebuild updated lensfun ebuild for multilib portage it also corrects the /lib32/lib64 problem you have
Well, if you feed CFLAGS="-O2 -march=core2 -pipe" to your x86 chroot, it's kind of natural that some programs get confused. I'd recommend picking a 32bit processor type... :) Works all fine here with -march=prescott (in an x86 chroot on a amd64 installation).
Even if -march=core2 magically could turn a 32-bit compiler (see CHOST) into a 64-bit one, the fact that it is being compiled as 32-bit should still use the correct lib dir. This is the only library out of all KDE/X11/GNU/etc with this bug, and Mario Fetka has already posted a fix for it.
(In reply to comment #6) > Even if -march=core2 magically could turn a 32-bit compiler (see CHOST) into a > 64-bit one, the fact that it is being compiled as 32-bit should still use the > correct lib dir. This is the only library out of all KDE/X11/GNU/etc with this > bug, and Mario Fetka has already posted a fix for it. That it's only occuring in one library does not mean that you're not misconfiguring your system. This is a typical case of "what goes in, comes out". Now, multilib support is a different problem (and should go in a different bug). Unfortunately, some of the stuff in Mario's ebuild is raising all the hairs at my neck in terms of proper variable use (CC="$(tc-getCC) ${CFLAGS}" comes to my mind), and the other stuff is cluttering the ebuild up unnecessarily. I am not inclined to commit it unless we (as in Gentoo dev discussion) come to the consensus that going multilib is an objective for the main portage tree.
I'm also fairly certain that Core2 CPUs do support 32-bit, and do not imply a 64-bit OS. If GCC was assuming Core2 implied 64-bit, I would argue it was a bug in GCC, but as it is GCC does the right thing. I am not on a multilib system. This is a strictly 32-bit install, with no trace of 64-bit in userland, other than my crossdev compiler that I use to build kernels. Finally, I have tested and confirmed that using -march=prescott instead of -march=core2 does NOT workaround this problem, and media-libs/lensfun-0.2.5-r1 still installs into /usr/lib64
if you just want to correct the libinstall problem the just add the --libdir=/usr/$(get_libdir) to correct the installdir
yes the buildsystem is broken the only really multib is the sed for the configscripts the CC=.. overwrites is for the configure script only to used the specified cc (so if you remove the CFLAGS you only correct direct run from gcc g++ / distcc) thee --cflags is used for the actual compile and the libdir is added to get the lib into the right directory thats all
Oook... I had a look at the code. Lensfun uses its own custom-made build system, written in python. 398 arch = platform.machine () 399 # Python 2.5 on windows returns empty string here 400 if (arch == "") or \ 401 (len (arch) >= 4 and arch [0] == "i" and arch [2:4] == "86" and arch [4:] == ""): 402 arch = "x86" Basically this also means that the configure results depend on the way python was compiled... I'd wager a guess that after re-compiling all of python with some reasonable CFLAGS the problem will just go away. With the current configuration, I dont have the slightest idea what the python platform.xxx() functions will return. In any case, I suggest you file an upstream bug, the build system is seriously broken and should be fixed (preferrably with a standard solution). Please add a link to the upstream bug report; we'll keep this bug open to track the issue.
the url to the bug http://developer.berlios.de/bugs/?func=detailbug&bug_id=18306&group_id=9034
Confirmed that Python 2.7 at least returns 'x86_64' for platform.machine() if the kernel is 64-bit, even if the OS and Python itself is 32-bit.
just add --libdir to ove(In reply to comment #13) > Confirmed that Python 2.7 at least returns 'x86_64' for platform.machine() if > the kernel is 64-bit, even if the OS and Python itself is 32-bit. just add --libdir to overwrite this behvior
Upstream changed the buildsystem to cmake hava not testet it.
(In reply to comment #15) > Upstream changed the buildsystem to cmake > hava not testet it. Made a snapshot and it seems to work. However they still have to figure out some CMake foo until they can release...
