Gentoo Archives: gentoo-alt

From: Michael Haubenwallner <haubi@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] AIX linking adventure
Date: Thu, 10 Feb 2011 17:26:58
In Reply to: Re: [gentoo-alt] AIX linking adventure by Perry Smith
On 02/10/11 15:14, Perry Smith wrote:
>>>>> ***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? >>> This is after my toolchain changes. >> How does this look like without your changes? > > In general, there were no "hardcoded" elements and the 0th element was simply: > > /usr/local/rvm/rubies/ruby-1.9.1-p378/lib:/usr/lib:/lib > > Let me know if that is sufficient. If not, I can do another build without my mod's.
Yes, this looks just fine IMO: Each shared object should be found in a "dynamic" path, using "runpath" at Index 0.
>> IIRC, "hardcoded" is what libtool uses for that kind of paths, >> but I'm fine with "fixed" too. > > Lets use existing terms if they exist. > hardcoded isn't too long. what is the opposite? non-hardcoded?
IIRC a shared object being subject to "runpath" search does have a "dynamic" path.
>>> 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. >> Which compiler did you use - gcc or xlc? > gcc 4.3.1 >> Does xlc search for 'ld' using PATH? > Good question. I don't know.
For each patch designed to be submitted upstream, the xlc case has to be kept in mind.
>> Usually, gcc does not, you'll have to configure it to use "/usr/local/aixbin/ld". > > collect2 (from gcc) calls ld. I'm using my "stock" gcc build and its working for me.
I understand you've built gcc-4.3.1 yourself without any patches, not configuring '--with-ld', right? Actually I did have problems[1] to bootstrap Prefix on Fedora/RedHat, where the host-gcc also does search for "ld" using ${PATH} environment variable. [1]
>>>> 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. >> Nope. The problem with LIBPATH set by java was that there is nothing >> like "soname". Iff my binary had searched for the /file/ "" >> (either archive or not) instead of "libiconv.a(", even with >> LIBPATH set to "/usr/lib" it would not have found "/usr/lib/libiconv.a" >> (without "" member), but continued along LIBPATH + runpath >> until it found the "" file in its usual place. > Hmmm... ok. I had forgotten that detail.
Yes, a detail - but a really important one for package managers.
>>>> Seems we have to agree on some terms to be used first. >>> Yes. >>> I like "fixed" for entries not affected by runtime search. >> "fixed" = "hardcoded" (see above). >>> 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" ? >> Which "PATH" ("path") do you refer to here that can be either empty or not? > > In the dump -H output above, there is a column called PATH. That PATH. I apologize for being > so consistently vague.
Ah, ok. But what is a "path dependency with no path" ?
>>>> 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. > Does the package (need to) work from the /image area or is this > just a temporary place used to create the tar file? In particular, > what about paths hard coded into the binaries? (Not the > paths in the binary's header but just paths hard coded in the code > like where to find my lisp files, etc. I know that *usually* there are > options to change them but there is still some default set at compile > time.
Nope, there is no need for anything to work from the /image area. This is just a temporary location for the package manager to identify/track/ship the files a package does install.
>> $ cd "/image" >> During step 3, the shared library gets installed as "/staging/final/lib/". >> Relinking "mybinary", the linker has to read that file, while encoding "/final/lib" >> (without "/staging") into "mybinary" as the search path for "". > > Shoot... you lost me. I think maybe /staging is the same as /image above?
Yes, "/staging" is the same as "/image" - apparently I've missed a few when replacing "/staging" by "/image". Sorry for confusion. But that's not the reason you got lost, is it?
> One question: with each of your experiments, do you dump out the > binary's "header" with dump -H?
Yes, at least usually.
> The reason I ask is I would expect > linking with an import file basically just put that piece, the #!<whatever> > into the binary's header at link time and then what happens at run > time is the same as if you had linked against a library.
Basically yes. The difference is that the values from "#! PATH/BASE(MEMBER)" are stored as-is into the binary's "Import File Strings" (as PATH BASE MEMBER), independent of how that Import File was specified on the linker's commandline, while for real shared objects it does make a difference how to specify them there.
> I remember toying with the import file inside the archive (and getting > frustrated at the lack of documentation) but I can't remember what > I found.
Agreed, even with the ld(1) manpage it is quite hard to get an idea of how to do it right. It took me years(!) of playing around/staring at that manpage/reading online docs and howto's/sleepless nights, until I figured out how I want to do "shared libraries" with "soname" (AIX does not have these terms) here. /haubi/ -- Michael Haubenwallner Gentoo on a different level


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