| 1 |
Hi Perry, |
| 2 |
|
| 3 |
On 02/09/11 17:47, Perry Smith wrote: |
| 4 |
> Lets start over. I don't think I'm making any progress but I'll give it one last go. |
| 5 |
> |
| 6 |
> Here is the output of dump -H of my installed ruby: |
| 7 |
> |
| 8 |
> /usr/local/rvm/rubies/ruby-1.9.1-p378/bin/ruby: |
| 9 |
> ***Import File Strings*** |
| 10 |
> INDEX PATH BASE MEMBER |
| 11 |
> 0 /usr/local/rvm/rubies/ruby-1.9.1-p378/lib:/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1:/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/../../..:/usr/lib:/lib |
| 12 |
> 1 librtl.a shr.o |
| 13 |
> 2 /usr/lib libc.a shr.o |
| 14 |
> 3 /usr/lib libpthread.a shr_comm.o |
| 15 |
> 4 /usr/lib libpthread.a shr_xpg5.o |
| 16 |
> 5 /usr/local/rvm/rubies/ruby-1.9.1-p378/lib libruby.so |
| 17 |
|
| 18 |
Is this with our without your intervention in ruby's build process and/or toolchain setup? |
| 19 |
|
| 20 |
> Except for librtl.a, there are no relative paths anywhere. That is one of my objectives (and your's I believe). |
| 21 |
|
| 22 |
There is no "relative" path by the usual means of "relative" /anywhere/ here, |
| 23 |
there are only "absolute" paths here - a "relative" path does not start with "/". |
| 24 |
However, librtl.a is subject to "runpath search", while the others are not |
| 25 |
due to "hardcoded" (unsure about this term) paths - but still "absolute" |
| 26 |
paths everywhere. |
| 27 |
|
| 28 |
Anyway - taking "relative" as "with runpath search", and "absolute" as |
| 29 |
"without runpath search" or even "hardcoded" here now. |
| 30 |
|
| 31 |
> It is using /usr/local/rvm/rubies/ruby-1.9.1-p378/lib/libruby.so . |
| 32 |
> If I move that to somewhere else, like |
| 33 |
> /usr/local/rvm/rubies/ruby-1.9.1-p378/lib/other/libruby.so |
| 34 |
> ruby does not work and setting LIBPATH does not fix the problem. |
| 35 |
|
| 36 |
Of course, due to the hardcoded paths no runpath search is performed. |
| 37 |
|
| 38 |
> Thus, for an object (I'll use the word "object" to mean shared object or an executable) |
| 39 |
|
| 40 |
Usually, "binary" is the term to be used here, but ok... |
| 41 |
|
| 42 |
> that is linked without only absolute paths, it will not work in the directory that it is built in. |
| 43 |
|
| 44 |
Let me grasp that: "without only absolute" paths "it will not work" where built. |
| 45 |
Isn't this a typo and should read "*with* only absolute" ? |
| 46 |
|
| 47 |
> In the case of ruby, it builds the library and executable in the same pass. |
| 48 |
> I think this is typical. |
| 49 |
|
| 50 |
Yep. |
| 51 |
|
| 52 |
> If you plan to run "make test" or "make check" (different packages call it different things) |
| 53 |
> before the install, you have a problem. |
| 54 |
|
| 55 |
Only if the paths are hardcoded - but this is unusual. |
| 56 |
|
| 57 |
> The way I solved that problem is to allow the object to have relative paths (or no path) |
| 58 |
> before it is installed, do the "make check", |
| 59 |
|
| 60 |
How exactly did you touch either the build process or the toolchain setup to "allow" that? |
| 61 |
|
| 62 |
> then either fix the object just before install or fix it just after the install. |
| 63 |
> I choose to fix it just after the install with "rl". |
| 64 |
|
| 65 |
Same here: How to touch the build process or the toolchain setup to get "rl" used? |
| 66 |
|
| 67 |
> I don't see how you can have an object that has only absolute paths after it is installed |
| 68 |
> *and* is able to be used before the install so that "make check" or "make test" can be run |
| 69 |
> (except by some weird chroot tricks but no one wants to go down that path). |
| 70 |
|
| 71 |
Yep, that doesn't work. |
| 72 |
|
| 73 |
> Lets pause here and see if we can come to an agreement on these two items. |
| 74 |
> 1) objets have only absolute paths after they are installed |
| 75 |
|
| 76 |
Still not clear to me: |
| 77 |
Do you actually /prefer/ hardcoded paths (without runpath search)? Why? |
| 78 |
|
| 79 |
Although runpath search is affected by LIBPATH, I'm just fine with that. |
| 80 |
This is the outcome of using "-L" and "-l" linker flags together. |
| 81 |
|
| 82 |
It is unusual to use hardcoded path (without runpath search), which is the |
| 83 |
result of using /absolute/path/to/the/library.so instead of "-L" and "-l". |
| 84 |
|
| 85 |
So when ruby's build system uses /absolute/path/to/the/library.so, you should |
| 86 |
try to fix that to use "-L" and "-l", as well as "-blibpath" eventually instead. |
| 87 |
|
| 88 |
> 2) The "make check" must work before package is installed. |
| 89 |
|
| 90 |
Yep, agreed on this one. |
| 91 |
|
| 92 |
Seems we have to agree on some terms to be used first. |
| 93 |
|
| 94 |
What else to say: |
| 95 |
When libtool knows for a platform that linking libraries results in hardcoded |
| 96 |
paths, or there is no such thing like LIBPATH environment variable to temporarily |
| 97 |
override the runpath, it actually /does/ "relink" the binaries during installation. |
| 98 |
OTOH, when the /absolute/path/to/the/library.so found at linktime is hardcoded into |
| 99 |
the resulting binary, installing into DESTDIR is broken - which is a prerequisite |
| 100 |
for package managers like portage to work properly. |
| 101 |
|
| 102 |
/haubi/ |
| 103 |
-- |
| 104 |
Michael Haubenwallner |
| 105 |
Gentoo on a different level |
Archives