Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-alt
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-alt@g.o
From: Michael Haubenwallner <haubi@g.o>
Subject: Re: AIX linking adventure
Date: Thu, 10 Feb 2011 18:26:32 +0100
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 libruby.so                              
>>>> 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] http://prefix-launcher.svn.sourceforge.net/viewvc/prefix-launcher?view=revision&revision=351

>>>> 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/ "libiconv.so.2"
>> (either archive or not) instead of "libiconv.a(libiconv.so.2)", even with
>> LIBPATH set to "/usr/lib" it would not have found "/usr/lib/libiconv.a"
>> (without "libiconv.so.2" member), but continued along LIBPATH + runpath
>> until it found the "libiconv.so.2" 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/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.
> 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/library.so".
>> Relinking "mybinary", the linker has to read that file, while encoding "/final/lib"
>> (without "/staging") into "mybinary" as the search path for "library.so".
> 
> 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


Replies:
Re: AIX linking adventure
-- Perry Smith
Re: AIX linking adventure
-- Perry Smith
References:
AIX linking adventure
-- Perry Smith
Re: AIX linking adventure
-- Michael Haubenwallner
Re: AIX linking adventure
-- Perry Smith
Re: AIX linking adventure
-- Michael Haubenwallner
Re: AIX linking adventure
-- Perry Smith
Re: AIX linking adventure
-- Michael Haubenwallner
Re: AIX linking adventure
-- Perry Smith
Re: AIX linking adventure
-- Michael Haubenwallner
Re: AIX linking adventure
-- Perry Smith
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: AIX linking adventure
Next by thread:
Re: AIX linking adventure
Previous by date:
Breaking news: Need to start over on AIX
Next by date:
Re: Breaking news: Need to start over on AIX


Updated Jun 18, 2012

Summary: Archive of the gentoo-alt mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.