I don't know who maintains this and there's no freedesktop@gentoo.org bugzilla alias, so I cannot assign it there. As such, I'm poking the last people to work on this package. I was doing a test run of catalyst today and expat got merged before baselayout, as such, it threw it's .libraries into /lib instead of /lib64... Thanks
Can you provide the build log? I'm on a multilib system and expat installs in /usr/lib64 just fine. econf is not called, --libdir is not overridden, and the makefile doesn't seem to override anything by itself
I can get you a build.log, but yours installs into the proper location likely because /lib is already a symlink to /lib64... remember, I'm *building* a stage1, so this would be at a much earlier point than you'd ever see on a live system. I'll get the log on the next run, since I'm way past expat and will need to clear my cache to get you the desired information.
The presence of the symlink on live filesystem will not change anything with respect to installation in DESTDIR afaics. As long as one package doesn't fail multilib-strict, everything should be fine.
Thanks Jakub! Someone should update the metadata.xml to point to the actual bugzilla alias. Anyway... Diego, here's the thing... the package installed files into /usr/lib (and not /usr/lib64) with the symlink missing. I would suspect that it's something in the Makefile that isn't properly respecting the LIBDIR. I've now got a list of several packages that do this. This is just one of many that I'm finding.
Err Chris, I'd like to tell you I'm not so newbie anymore, I know exactly the problem you refer to (I found and fixed more than a couple of packages already), and I can't seem to find it in expat, for two reasons: a) emerged copy of expat does not have files installed in /usr/lib; when we do the make install in src_install() we do not have the lib -> lib64 symlink in $D so if the package installs stuff in /usr/lib, then that would be the path listed in the vdb; multilib-strict feature checks just for that, and I have it enabled in my system, expat does not fail the test; b) I skimmed through the Makefile.in file and I couldn't find anywhere where libdir was not respected; the ebuild doesn't do anything strange either; I suspect, if anything, a bug in portage's econf, but to know that for sure I'd have to see the build log.
Ugh... OK. This is definitely a problem elsewhere. It seems to be something with calling get_libdir. I've checked the profile and even switched to another profile and it is still doing the same thing. It's either something with econf or something else that I haven't discovered yet. Sorry for all the confusion and trouble.
