FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Alt

 
 
LinkBack Thread Tools
 
Old 04-23-2010, 01:55 AM
Johan Hattne
 
Default 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
 
Old 04-23-2010, 08:02 AM
Fabian Groffen
 
Default 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
 
Old 04-23-2010, 05:17 PM
Johan Hattne
 
Default 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
 

Thread Tools




All times are GMT. The time now is 01:15 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org