Hi Perry,

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:
> 
> /usr/local/rvm/rubies/ruby-1.9.1-p378/bin/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-aix5.3.0.0/4.3.1:/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/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"
paths everywhere.

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 
> /usr/local/rvm/rubies/ruby-1.9.1-p378/lib/other/libruby.so
> 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.

Yep.

> 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.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level