1 |
Dear all; |
2 |
|
3 |
I've been playing around a bit with prefixifying ebuilds for software |
4 |
that is only distributed in binary form. An example of what I mean is |
5 |
dev-lang/icc, but there are many others. I'm not done playing, but |
6 |
since dev-lang/icc and friends were prefix-keyworded recently, I'd like |
7 |
to bring it up, nevertheless. |
8 |
|
9 |
Static binaries are OK, but problems crop up during dynamic linking: |
10 |
whether there is an rpath in the binary, or the runtime linker of the |
11 |
host uses the paths from its configuration files, we'll probably end up |
12 |
linking against libraries outside the prefix. For an x86 prefix on an |
13 |
x86 host things may still appear to work, but you'll notice as soon as |
14 |
you run the x86 programs on an amd64 host. |
15 |
|
16 |
As far as I can see, setting the rpath is one way to solve the problem, |
17 |
and I've been toying around with patchelf to accomplish that (chrpath |
18 |
won't work, because it doesn't allow rpaths to grow). To my mind, the |
19 |
process is conceptually similar to the "shebang prefixing" that happens |
20 |
for shell scripts, so I'm wondering whether it would make sense to |
21 |
implement it in a similar fashion, e.g. |
22 |
|
23 |
for each ELF file { |
24 |
prepend ${EPREFIX} to each rpath element |
25 |
prepend ${EPREFIX}/lib:${EPREFIX}/usr/lib to rpath |
26 |
} |
27 |
|
28 |
somewhere in portage. At least this allowed me to use icc to compile a |
29 |
32 bit helloworld using an x86-prefix on both x86 and amd64. |
30 |
|
31 |
// Cheers; Johan |