Re: [gentoo-alt] AIX linking adventure

[Perry Smith]

On Feb 9, 2011, at 4:33 PM, Michael Haubenwallner wrote:

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

This is after my toolchain changes.

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

Yea.  I need to use better terms.  but I think you are following me.  I'm
using the same term to mean two different things.

In the 0'th entry above, there are no entries like "." (so in that case, that term "relative path"
or "absolute path" is correct.)

The 1st entry is what I was calling "relative" but as you point out, that isn't the right term.
"affected by run path search" is too long for me. :-)

The 2nd through 5th items are those I was calling "absolute" but really they should be
called "not affected by run path search".  Perhaps "fixed" in this case would work?  
non-LIBPATH-able?

>
>> 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" ?

Yes.  typo.  sorry.  I really do go back and proof read my emails.

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

I put my ld in /usr/local/aixbin/ld and I put /usr/local/aixbin as the first element of PATH.
So my ld gets called instead of the real ld.  My ld monkeys with things.

After everything is installed, I go back through with "rl".  I did this by hand at the present time.
In the limited case that I'm experimenting with, everything is installed off in a directory that
is just the new ruby install.  I can do a find for the binary files and then call rl on them and it
will make the changes.

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

See above.

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

I thought this was one of your objectives based on the fact that java sets LIBPATH
to something weird and it breaks everything.

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

Yes.  

I like "fixed" for entries not affected by runtime search.

The other tact would be to note that PATH is either empty or not.

"A path dependency with no path" or "a dependency with a path" ?

"binary" instead of "object" sounds better to me.

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

I understood that part -- but

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

Didn't understand this part.  In particular, from the comma to the end ", installing ..."

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