Re: [gentoo-alt] AIX linking adventure

[Perry Smith]

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:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000553       0x0000008a       0x00000141       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000006       0x00008660       0x00006307       0x000087a1       


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

Except for librtl.a, there are no relative paths anywhere.  That is one of my objectives (and your's I believe).

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.  Thus, for an object (I'll use the word "object" to mean shared object or an executable) that is linked without only absolute paths, it will not work in the directory that it is built in.  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.

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

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

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
2) The "make check" must work before package is installed.


On Feb 8, 2011, at 4:02 PM, Michael Haubenwallner wrote:

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