the .a file indices on all installed libraries from portage are incorrect because they reference paths from the destroot that they were compiled/`make install`ed to. To work, they need ranlib run on them on the livefs, but this is bad because it will modify the md5 thus making portage not want to touch the file. The fix is in debate right now.
Because of how portage's mergme function works, this cannot be an ebuild/eclass/ebuild.sh hack. This updating the .a files is easy, 24 bytes in, dump the mtime as char's. This modification would need to be done in mergeme, which would be a bit tricky. Sidenote, it's not an issue w/ the constructed indice's; issue is purely that it thinks the archive's toc is out of date, and refuses linkage (because it's stupid/mean, take your pick).
hmm. for english being my main/pretty much only language, I seem to truly suck at writing coherent sentences... bah. Either way, the fix for this is either A) running ranlib (kind of expensive, since only 12 bytes need to change), B) writing the file's merged mtime 24 bytes into the ar. I prefer B personally. Problem is, how to implement this; I'd prefer implementing a hook, but that could very well be messy/QA-fun. Implementing the ar toc hack in mergeme isn't hard, but not much for introducing arch specific hacks into integral functions. Portage devs, thoughts? Note this wouldn't be an issue if we got rid of the md5/mtime hack, and went w/ refcounts (mergeme updates the files mtime automatically).
Created attachment 37915 [details, diff] ranlib-hack.patch This is a patch against .51_pre20; it fixes the ranlib problem, also ensuring the CONTENTS file has the correct md5 for the new archive. Kind of hackish, not much for this being in portage proper (although again, we'd have to either A) implement a profile hook, or B) do away with the md5+mtime hack)
Comment on attachment 37915 [details, diff] ranlib-hack.patch Round 2 shortly.
Created attachment 37928 [details, diff] ranlib-hack.patch v2 Alright, using this, seems to work fine (finally). It's a bit noisy when updating an archive's toc, but that's fine for the moment; if it screws up, I want to know where it bailed (and want access to the generated .a so I can fix this). Ultimately, could just directly call ranlib, but would prefer not to fully regenerate the archive; when it was created, might've used some funky options (which we would have to match).
Added url to darwin docs on ar format; basically what I read to create the fix...
Created attachment 37934 [details, diff] ranlib-hack.patch v3 Ugh... I'm a tool. wanted x % 2 (+1 if it's odd), not x % 1. bah.
Wouldn't it be possible some way to actually have the correct location in the archives in the first place? Such fixes should probably also be performed on shared libraries that use the rpath linking option. Would it be very complicated to maintain a lib rewriter (for postprocessing, similar to strip) for these issues?
"Wouldn't it be possible some way to actually have the correct location in the archives in the first place?" Read my comments above; in a static archive, there is no such thing as location... The package installs the .a file into the image directory, with the correct mtime, and portage then goes and re-stamps all filles that it merges to the livefs with a new mtime. Linker detects the internal mtime for the symbol it's after differs from the file's mtime, and re-updates. That, is the issue, nothing regarding locations. Literally, rewrite the header for each entry with the new mtime, regen the md5, and merge it. Down the line, refcounts will likely be used instead of the existing md5+mtime solution- this isn't going to be changed now however, since we're stabling .51. So... this solution goes into .51, assuming I get some feedback on the code. Afterwards, likely in .52, we implement refcounts instead of the current "lets rely on a known horked md5+mtime solution", and this entire problem goes away (including the need for this code). Meanwhile, commentary on this please; I've tested it, as has hansmai, but I'd like a few more people to take it for a spin.
Will be out in the next .51 release; .51_pre21 I'd think.
Tested here with libevent, libdnet and libpcre. Scanssh linked fine against the first two, and nmap linked fine against libpcre.
Seems A-OK here... Lets close this bug up, shall we? (Reopen if I'm wrong)
ppc-macos profile doesn't set ARCH=macos anymore. Shouldn't we use ppc-macos keyword here?
Changed in cvs. Out in -r3.
using -r3 i've had no problems. i'm closing this again. beat me with a stick if I'm wrong
