On 02/09/11 17:47, Perry Smith wrote:
> Lets start over. I don't think I'm making any progress but I'll give it one last go.
> Here is the output of dump -H of my installed ruby:
> ***Import File Strings***
> INDEX PATH BASE MEMBER
> 0 /usr/local/rvm/rubies/ruby-1.9.1-p378/lib:/usr/local/lib/gcc/powerpc-ibm-aix22.214.171.124/4.3.1:/usr/local/lib/gcc/powerpc-ibm-aix126.96.36.199/4.3.1/../../..:/usr/lib:/lib
> 1 librtl.a shr.o
> 2 /usr/lib libc.a shr.o
> 3 /usr/lib libpthread.a shr_comm.o
> 4 /usr/lib libpthread.a shr_xpg5.o
> 5 /usr/local/rvm/rubies/ruby-1.9.1-p378/lib libruby.so
Is this with our without your intervention in ruby's build process and/or toolchain setup?
> Except for librtl.a, there are no relative paths anywhere. That is one of my objectives (and your's I believe).
There is no "relative" path by the usual means of "relative" /anywhere/ here,
there are only "absolute" paths here - a "relative" path does not start with "/".
However, librtl.a is subject to "runpath search", while the others are not
due to "hardcoded" (unsure about this term) paths - but still "absolute"
Anyway - taking "relative" as "with runpath search", and "absolute" as
"without runpath search" or even "hardcoded" here now.
> It is using /usr/local/rvm/rubies/ruby-1.9.1-p378/lib/libruby.so .
> If I move that to somewhere else, like
> ruby does not work and setting LIBPATH does not fix the problem.
Of course, due to the hardcoded paths no runpath search is performed.
> Thus, for an object (I'll use the word "object" to mean shared object or an executable)
Usually, "binary" is the term to be used here, but ok...
> that is linked without only absolute paths, it will not work in the directory that it is built in.
Let me grasp that: "without only absolute" paths "it will not work" where built.
Isn't this a typo and should read "*with* only absolute" ?
> In the case of ruby, it builds the library and executable in the same pass.
> I think this is typical.
> If you plan to run "make test" or "make check" (different packages call it different things)
> before the install, you have a problem.
Only if the paths are hardcoded - but this is unusual.
> The way I solved that problem is to allow the object to have relative paths (or no path)
> before it is installed, do the "make check",
How exactly did you touch either the build process or the toolchain setup to "allow" that?
> then either fix the object just before install or fix it just after the install.
> I choose to fix it just after the install with "rl".
Same here: How to touch the build process or the toolchain setup to get "rl" used?
> I don't see how you can have an object that has only absolute paths after it is installed
> *and* is able to be used before the install so that "make check" or "make test" can be run
> (except by some weird chroot tricks but no one wants to go down that path).
Yep, that doesn't work.
> Lets pause here and see if we can come to an agreement on these two items.
> 1) objets have only absolute paths after they are installed
Still not clear to me:
Do you actually /prefer/ hardcoded paths (without runpath search)? Why?
Although runpath search is affected by LIBPATH, I'm just fine with that.
This is the outcome of using "-L" and "-l" linker flags together.
It is unusual to use hardcoded path (without runpath search), which is the
result of using /absolute/path/to/the/library.so instead of "-L" and "-l".
So when ruby's build system uses /absolute/path/to/the/library.so, you should
try to fix that to use "-L" and "-l", as well as "-blibpath" eventually instead.
> 2) The "make check" must work before package is installed.
Yep, agreed on this one.
Seems we have to agree on some terms to be used first.
What else to say:
When libtool knows for a platform that linking libraries results in hardcoded
paths, or there is no such thing like LIBPATH environment variable to temporarily
override the runpath, it actually /does/ "relink" the binaries during installation.
OTOH, when the /absolute/path/to/the/library.so found at linktime is hardcoded into
the resulting binary, installing into DESTDIR is broken - which is a prerequisite
for package managers like portage to work properly.
Gentoo on a different level