| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 27, 2010 17:15 UTC (Sun) by nix (subscriber, #2304)In reply to: SELF: Anatomy of an (alleged) failure by Tet Parent article: SELF: Anatomy of an (alleged) failure
Ah, right. So we don't need completely arbitrary fat binaries at all: we need a 'fat dlopen()'.
I suspect -- though it's a kludge -- you could do this with an LD_PRELOADed wrapper around dlopen() which tweaks the filename appropriately, and slight changes to the downloading parts of e.g. firefox to put its dynamically loaded stuff in per-arch subdirectories when autodownloaded. dlopen() is not a hidden symbol so should be vulnerable to interposition.
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 17:55 UTC (Sun) by Tet (subscriber, #5433) [Link] So we don't need completely arbitrary fat binaries at all: we need a 'fat dlopen()'To solve this particular problem, yes. But then Ryan's FatELF release supported dlopen()ing fat shared libraries.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 20:36 UTC (Sun) by nix (subscriber, #2304) [Link]
Yes, but if that's all you need to do, the kernel side of FatELF is superfluous.
SELF: Anatomy of an (alleged) failure Posted Jun 28, 2010 8:53 UTC (Mon) by Tet (subscriber, #5433) [Link]
Oh agreed, and in this particular case, it's not necessary. However, there are other situations where full fat binaries might be a win. I just get extremely annoyed by people claiming that the whole concept of multi-arch binaries is useless just because they happen to not have a valid use for them, and are unable to see that others might have.
SELF: Anatomy of an (alleged) failure Posted Jun 28, 2010 13:22 UTC (Mon) by nix (subscriber, #2304) [Link]
The attitude appears to be 'distributors don't need them therefore they are useless'. This seems, to me, more than a little shortsighted...
|
|||||||||||||