Gentoo Archives: gentoo-alt

From: Michael Haubenwallner <haubi@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] AIX linking adventure
Date: Wed, 09 Feb 2011 22:34:00
In Reply to: Re: [gentoo-alt] AIX linking adventure by Perry Smith
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
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/ . > If I move that to somewhere else, like > /usr/local/rvm/rubies/ruby-1.9.1-p378/lib/other/ > 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/ instead of "-L" and "-l". So when ruby's build system uses /absolute/path/to/the/, 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/ 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


Subject Author
Re: [gentoo-alt] AIX linking adventure Perry Smith <pedzsan@×××××.com>