Re: [gentoo-alt] AIX linking adventure

[Michael Haubenwallner]

Hi Perry!

On 02/08/11 19:36, Perry Smith wrote:
> On Feb 8, 2011, at 2:49 AM, Michael Haubenwallner wrote:
>> On 02/08/2011 01:35 AM, Perry Smith wrote:
>>> I wrote a front end to AIX's ld command as well as a relink command I'm calling "rl".
>> Actually, in Prefix we already do wrap AIX' ld in sys-devel/binutils-config
>> to get the runpaths (the -blibpath argument) right.
>> There is an RFC[1] for the way I want to have shared libraries being created on AIX.
>> [1] http://lists.gnu.org/archive/html/libtool/2011-01/msg00023.html
>
> I am not on the libtool list.  I did not read that thread yet but I will here shortly.

You might consider subscribing to that Gentoo bug[1], its URL refers
to the libtool thread, and I'm usually adding progress there.

[1] http://bugs.gentoo.org/show_bug.cgi?id=213277

> I need some "netiquette" help.  Should I plop my thoughts / questions about that
> thread into this thread or start a new thread?  I get confused either way :-)  (Maybe
> I'm special that way.)

Eventually we can sort out your concerns here (first).

>>> https://github.com/pedz/aixbin
>>
>> Commenting on 'Readme.markdown' found there:
>> Why do you move '-blibpath' arguments to '-L' arguments?
>> IMO, the other way round would make more sense actually.
>> Why do you need 'rl' (relink) at all?
>
> For ruby, their libpath was a complete mistake.

Ohw, seems there's need to fix your view on the libpath/runpath issue,
as everything you describe here actually is how it should be done:

Usually, compilers are installed as part of the host system into somewhere
like /usr, where /usr/lib usually is the search path for any installed
library at linktime (called "linkpath", set via "-L" linker flag), and
either "/usr/lib:/lib" or even "/lib:/usr/lib" is the search path at
runtime (called "runpath", set via "-blibpath" linker flag).

> They did not include the path to gcc's library.

Nobody but the compiler and/or the system should know the system's and
compiler's library directories. It is up to the compiler-, linker- and
loader-setup to find the system's and especially the compiler's libraries
at both linktime and runtime.

This exactly is the (major) reason why in Prefix we do wrap the linker
(as well as the compiler) to get gcc's and Prefix' (being the (sub)system)
library directories into both linkpath and runpath.

> They did not have a -L /path/to/where/they/would/install

The currently built package's libraries must not be linked from the target
installation directory. Imagine an old version of a library is already
installed there, and you want to upgrade the package - as is the usual
case with package managers (being either humans or software).

And if there are dependent libraries, they either are installed in system's
library directories the compiler/linker setup knows anyway, or the package
manager should add their locations via something like LDFLAGS or the like.

So while the new binaries must _not_ be /linked/ against the already installed
libraries provided by another instance of the package just built, ...

> but they did have -blibpath:/path/to/where/they/would/install:/usr/lib:/lib

..., at runtime (after installing) the libraries have to be /loaded/ from there.

One AIX specific thing here is that the AIX loader cannot be configured to
search additional directories, so the binaries have to contain the whole runpath.
While the linker does search /usr/lib and /lib at linktime, it will not add
these paths to the runpath when an explicit runpath is specified via -blibpath.
This is why "/usr/lib:/lib" is specified with -blibpath too.

> And... the executable would never work in the directory
> where it was built in.  It would work only after the package was
> installed (moved).  I don't know how they were going to do
> the "test" or "check" phase which I'm sure Ruby has.

They most likely set the LIBPATH environment variable to the local
library directory. This is one of the rare use cases where environment
variables like LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH are useful.

> I took their mistake as a symptom as a general practice.  i.e.
> the general population somehow thinks that libpath substitutes for
> -L and it does not.  I'm interested to hear of your experience but
> I can't think of a time where open source understood what libpath
> (inside the object) could/should be used for.

Actually, the Ruby guys seem to have done it "right":
If you were using xlc (from /usr/bin), or even gcc from the
"AIX Toolbox for Linux applications", so both are "installed
with the host system", you might not have had any problem.

> The Ruby guys did have a fairly reasonable fear.  They did not want
> to have just -L . and -L .., etc and not set the libpath because the -L .
> adds that to the internal libpath and that creates what they called a
> security risk.

The explicit '-blibpath' avoids recording the (relative) local library
paths passed via '-L' into the runpath:

*) Using buildtime paths (either relative or not) for -L, the linker is able to
find the new libraries (this is called "linktime"), before installation.
*) Using target paths (absolute only) for -blibpath, the loader is able to
find the installed library (this is called "runtime"), after installation.

> But, the problem is that the dot needs to be in the internal
> libpath while the executable is in the directory it was built in.

*) Using local paths (either relative or not) for LIBPATH, the loader is able to
find the new library (there is no such term "testtime"), before installation.

> The purpose for rt is after the install.

<snipped anything related to 'rt' (relink?), as it should be obsolete now>

> I also had a rather self imposed limitation to work around.
> I am trying to get "rvm" to work and rvm thinks it knows how to
> unpackage, configure, build, and install without any user
> intervention.  To get that to work, I had to hook in at the ld
> point and then, after the fact, fix the resulting files after they
> are installed.

This actually is a not so uncommon problem:
It usually does not work that well using more than one package manager
at a time - portage and rvm in this case.

>>> I've used this only for Ruby -- and it was in fact Ruby that caused me to do this.
>>> Their out of the box system does not work at all for AIX if the prefix directory is not the same as GCC's.
>>> WIth this, I can now use rvm on AIX and do "rvm install 1.9.1" and it will complete successfully without my fingers leaving my hands.

Which directory (called "prefix") do you tell "rvm" to install to?
Have you tried this while having your Gentoo Prefix instance in your
environment (using /your/gentoo/prefix/startprefix)?

>> Haven't used/installed Ruby on any platform yet: What is 'rvm' ?
> rvm is  "Ruby Version Manager".  rvm allows completely independent
> versions of Ruby (1.8.7, 1.9.1, MacRuby, etc).  Each version can have
> its own independent sets of gems (called gemsets) so an application
> can use its own version of Ruby and its own set of gems.  I can set up
> an environment on my development laptop and then fairly easily replicate
> this environment on my staging server and production server.  It solves
> many problems I have when trying to have three or four Rails apps
> on the same host.  (sorry for the long winded reply).

Basically this also is what Gentoo Prefix is for - having multiple instances
of similar things set up on one machine. However, eventually it is possible
to have multiple Ruby versions within one instance of Gentoo Prefix (and even
Gentoo Linux) set up in some package-managed way (using portage as the
package manager instead of rvm).

>>> I mentioned this idea on this list before but it didn't fly very well.
>>> I'm not sure if it was completely understood.
>> I fail to find that post you're referring to. Has it been within one
>> of the threads we already created together, and I've overlooked it?
>
> I *think* this is the post but it got munged:
> http://archives.gentoo.org/gentoo-alt/msg_d16e4dce43974e6926eedf04a3b8fb36.xml
>
> My archive is this (snipped out).

Ok, found it in my archives too - for mailing list managers
it is easier to receive plain text mails, no html.

> The time stamp is Tue, Dec 14, 2010 at 6:25 PM (to the gentoo-alt list)
>
>> Also, the guy I'm talking to mentioned rtl_enable -s.  I've not used it but it seems like it might make life a lot easier.

Still I do think we don't have any use for 'rtl_enable' when
we are able to /create/ corrent shared libraries firsthand.
rtl_enable is designed to "fix" shared objects for one's needs
when there is no sourcecode available.

>>> This is more of a proof of concept at this stage.  I'm going to putter around and try and use it on other packages.
>>
>> For packages not aware of AIX at all:
>> How would this require their build systems to be patched?
>>
>>> "rl" could be enhanced to take "from" and "to" directories.

The above "rt" is a typo and should be "rl"?

>>> If you wanted to change files installed in /some/old/directory and put them into /some/new/directory, rl could easily modified do that.
>>
>> In which context do you need this use case?
>
> With putting absolute paths into the objects, we are effectively nullifying the possible benefit of the LIBPATH environment.  I think we
> both agree that that benefit is questionable but others might like it.  So if someone wants to move where I built a package from
> /usr/local to /opt, the first step would be to change the internal absolute paths to each dependency.  There would be other obstacles too
> like any internal paths of the executables but often there are command line arguments to change those.  e.g. you can give
> emacs directions on where to find its lisp files but you can not magically tell the loader where to find emacs' dependent libraries.
> A user once could via LIBPATH but that isn't going to work now with absolute internal paths.  rl gives that possibly useful option back
> to the user.

Well, moving a binary package from /usr/local to /opt is a
completely different use case than the one above, which was:
compile, run from build directory, install (into /usr/local).

(replace "/usr/local/" by "/gentoo/prefix/usr/")

>> And how would you do that on Linux?
>
> I don't know squat about Linux.
> Part of my frustration is everyone appears to want to make AIX fit into the Linux way.

The linkpath/runpath problem isn't specific to Linux in any way, it is
an universal problem when managing packages - on /any/ operating system.

I did go through these /very/ same linkpath/runpath hell on Linux already,
and in Prefix we do the same linkpath/runpath trickery on /any/ platform.

Welcome to "rpath hell", "dll hell", "dependency hell", "distribution hell",
"<whatever> hell"!

The only problem AIX really does have is the lack of something like what is known as
"DT_SONAME" in ELF/SystemV-world[2], being immediately encoded into the shared objects.
The reason for this being a problem is not that ELF does have it, it is because
such a mechanism actually is necessary for managing packages.
However, it is possible to emulate the "DT_SONAME" thing with Import Files ...

[2] Linux, Solaris, (recent) HP-UX, *BSD, ...

> My objective is subtly but significantly different.
> I want to get open source packages onto AIX.

Same goal here.
However, Linux (as "the" open source platform these days) is "the"
reference platform open source packages most often are written for.

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