Binary-only distributions on linux
Dear all;
I've been playing around a bit with prefixifying ebuilds for software that is only distributed in binary form. An example of what I mean is dev-lang/icc, but there are many others. I'm not done playing, but since dev-lang/icc and friends were prefix-keyworded recently, I'd like to bring it up, nevertheless. Static binaries are OK, but problems crop up during dynamic linking: whether there is an rpath in the binary, or the runtime linker of the host uses the paths from its configuration files, we'll probably end up linking against libraries outside the prefix. For an x86 prefix on an x86 host things may still appear to work, but you'll notice as soon as you run the x86 programs on an amd64 host. As far as I can see, setting the rpath is one way to solve the problem, and I've been toying around with patchelf to accomplish that (chrpath won't work, because it doesn't allow rpaths to grow). To my mind, the process is conceptually similar to the "shebang prefixing" that happens for shell scripts, so I'm wondering whether it would make sense to implement it in a similar fashion, e.g. for each ELF file { prepend ${EPREFIX} to each rpath element prepend ${EPREFIX}/lib:${EPREFIX}/usr/lib to rpath } somewhere in portage. At least this allowed me to use icc to compile a 32 bit helloworld using an x86-prefix on both x86 and amd64. // Cheers; Johan |
Binary-only distributions on linux
On 22-04-2010 20:55:58 -0500, Johan Hattne wrote:
> As far as I can see, setting the rpath is one way to solve the problem, > and I've been toying around with patchelf to accomplish that (chrpath > won't work, because it doesn't allow rpaths to grow). To my mind, the I'd like to add it to the tree when I've got time to make an ebuild for it. > process is conceptually similar to the "shebang prefixing" that happens > for shell scripts, so I'm wondering whether it would make sense to > implement it in a similar fashion, e.g. > > for each ELF file { > prepend ${EPREFIX} to each rpath element > prepend ${EPREFIX}/lib:${EPREFIX}/usr/lib to rpath > } > > somewhere in portage. At least this allowed me to use icc to compile a > 32 bit helloworld using an x86-prefix on both x86 and amd64. Do you have an idea how to automagically select the correct ELF files? Most already contain the required paths of course. I don't quickly see how we can pick the right ones out there to "fix", but perhaps that's possible. Otherwise, maybe a function in prefix.eclass that does the job somehow? -- Fabian Groffen Gentoo on a different level |
Binary-only distributions on linux
On 04/23/10 03:02, Fabian Groffen wrote:
> On 22-04-2010 20:55:58 -0500, Johan Hattne wrote: >> As far as I can see, setting the rpath is one way to solve the problem, >> and I've been toying around with patchelf to accomplish that (chrpath >> won't work, because it doesn't allow rpaths to grow). To my mind, the > > I'd like to add it to the tree when I've got time to make an ebuild for > it. Here's a start (lines broken courtesy of mailer). "ebuild test" works for me. EAPI="3" DESCRIPTION="A small utility to modify the dynamic linker and RPATH of ELF executables" HOMEPAGE="http://nixos.org/patchelf.html" SRC_URI="http://hydra.nixos.org/build/114505/download/2/${PN}-${PV}.tar.bz2" KEYWORDS="~x86-linux" LICENSE="GPL-3" SLOT="0" src_configure() { econf --docdir="${EROOT}/usr/share/doc/${PN}-${PV}" || die "configure failed" } src_install() { emake install DESTDIR="${D}" || die "make install failed" } From what I understand, it doesn't work on Solaris (why?), so Linux only. >> process is conceptually similar to the "shebang prefixing" that happens >> for shell scripts, so I'm wondering whether it would make sense to >> implement it in a similar fashion, e.g. >> >> for each ELF file { >> prepend ${EPREFIX} to each rpath element >> prepend ${EPREFIX}/lib:${EPREFIX}/usr/lib to rpath >> } >> >> somewhere in portage. At least this allowed me to use icc to compile a >> 32 bit helloworld using an x86-prefix on both x86 and amd64. > > Do you have an idea how to automagically select the correct ELF files? > Most already contain the required paths of course. I don't quickly see > how we can pick the right ones out there to "fix", but perhaps that's > possible. Otherwise, maybe a function in prefix.eclass that does the > job somehow? Not sure which "correct" ELF files you mean: for now I just scanned the whole image-directory for ELF files and fixed all of them up in a ad hoc sort of way. The assumption is that if there's no rpath, then "${EPREFIX}/lib:${EPREFIX}/usr/lib" is probably reasonable. If there is an rpath "/A:/B", then "${EPREFIX}/lib:${EPREFIX}/usr/lib:${EPREFIX}/A:${EPREFIX}/B" may be OK. But no, I didn't actually check whether the fixed rpaths can be used to resolve dynamic linking. And I haven't even thought about the possibility that there may be ELF files which shouldn't have their rpath "fixed". This may very well be stupid in ways I haven't yet realised--I'm still playing around with it. But since I think that the binary-only ebuilds should make it into prefix sooner (or later), I figure this is the place to bring it up. // Cheers; Johan |
| All times are GMT. The time now is 12:42 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.