Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 58848 - .a files and incorrect ar mtimes
Summary: .a files and incorrect ar mtimes
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: PPC All
: High blocker (vote)
Assignee: Portage team
Keywords: InVCS
Depends on:
Blocks: 57856 57858 57868 57917 58006 58165 58215 58713 58811 59271 59571 61394 61403
  Show dependency tree
Reported: 2004-07-29 19:52 UTC by Hasan Khalil (RETIRED)
Modified: 2004-11-12 18:57 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

ranlib-hack.patch (ranlib-hack.patch,949 bytes, patch)
2004-08-22 01:39 UTC, Brian Harring
Details | Diff
ranlib-hack.patch v2 (ranlib-hack.patch,1.80 KB, patch)
2004-08-22 04:04 UTC, Brian Harring
Details | Diff
ranlib-hack.patch v3 (ranlib-hack.patch,1.70 KB, patch)
2004-08-22 05:36 UTC, Brian Harring
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hasan Khalil (RETIRED) gentoo-dev 2004-07-29 19:52:23 UTC
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.
Comment 1 Brian Harring gentoo-dev 2004-08-22 00:03:02 UTC
Because of how portage's mergme function works, this cannot be an ebuild/eclass/ 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).
Comment 2 Brian Harring gentoo-dev 2004-08-22 00:22:27 UTC
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).
Comment 3 Brian Harring gentoo-dev 2004-08-22 01:39:57 UTC
Created attachment 37915 [details, diff]

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 4 Brian Harring gentoo-dev 2004-08-22 02:21:28 UTC
Comment on attachment 37915 [details, diff]

Round 2 shortly.
Comment 5 Brian Harring gentoo-dev 2004-08-22 04:04:55 UTC
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).
Comment 6 Brian Harring gentoo-dev 2004-08-22 04:59:23 UTC
Added url to darwin docs on ar format; basically what I read to create the fix...
Comment 7 Brian Harring gentoo-dev 2004-08-22 05:36:03 UTC
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.
Comment 8 Paul de Vrieze (RETIRED) gentoo-dev 2004-08-23 03:22:01 UTC
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?
Comment 9 Brian Harring gentoo-dev 2004-08-23 08:18:03 UTC
"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.
Comment 10 Brian Harring gentoo-dev 2004-08-23 11:00:25 UTC
Will be out in the next .51 release; .51_pre21 I'd think.
Comment 11 Lina Pezzella (RETIRED) gentoo-dev 2004-08-23 18:53:25 UTC
Tested here with libevent, libdnet and libpcre.  Scanssh linked fine against the first two, and nmap linked fine against libpcre.
Comment 12 Hasan Khalil (RETIRED) gentoo-dev 2004-09-18 04:03:58 UTC
Seems A-OK here... Lets close this bug up, shall we?
(Reopen if I'm wrong)
Comment 13 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-23 23:22:28 UTC
ppc-macos profile doesn't set ARCH=macos anymore.
Shouldn't we use ppc-macos keyword here?
Comment 14 Jason Stubbs (RETIRED) gentoo-dev 2004-10-24 00:32:37 UTC
Changed in cvs. Out in -r3.
Comment 15 Kito (RETIRED) gentoo-dev 2004-11-12 18:57:24 UTC
using -r3 i've had no problems. i'm closing this again. beat me with a stick if I'm wrong