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
Message-Id: 4D541FC8.3000700@gentoo.org
In Reply to: Re: [gentoo-alt] AIX linking adventure by Perry Smith
1 On 02/10/11 15:14, Perry Smith wrote:
2 >>>>> ***Import File Strings***
3 >>>>> INDEX PATH BASE MEMBER
4 >>>>> 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
5 >>>>> 1 librtl.a shr.o
6 >>>>> 2 /usr/lib libc.a shr.o
7 >>>>> 3 /usr/lib libpthread.a shr_comm.o
8 >>>>> 4 /usr/lib libpthread.a shr_xpg5.o
9 >>>>> 5 /usr/local/rvm/rubies/ruby-1.9.1-p378/lib libruby.so
10 >>>> Is this with our without your intervention in ruby's build process and/or toolchain setup?
11 >>> This is after my toolchain changes.
12 >> How does this look like without your changes?
13 >
14 > In general, there were no "hardcoded" elements and the 0th element was simply:
15 >
16 > /usr/local/rvm/rubies/ruby-1.9.1-p378/lib:/usr/lib:/lib
17 >
18 > Let me know if that is sufficient. If not, I can do another build without my mod's.
19
20 Yes, this looks just fine IMO:
21 Each shared object should be found in a "dynamic" path, using "runpath" at Index 0.
22
23 >> IIRC, "hardcoded" is what libtool uses for that kind of paths,
24 >> but I'm fine with "fixed" too.
25 >
26 > Lets use existing terms if they exist.
27 > hardcoded isn't too long. what is the opposite? non-hardcoded?
28
29 IIRC a shared object being subject to "runpath" search does have a "dynamic" path.
30
31 >>> I put my ld in /usr/local/aixbin/ld and I put /usr/local/aixbin as the first element of PATH.
32 >>> So my ld gets called instead of the real ld. My ld monkeys with things.
33 >> Which compiler did you use - gcc or xlc?
34 > gcc 4.3.1
35 >> Does xlc search for 'ld' using PATH?
36 > Good question. I don't know.
37
38 For each patch designed to be submitted upstream, the xlc case has to be kept in mind.
39
40 >> Usually, gcc does not, you'll have to configure it to use "/usr/local/aixbin/ld".
41 >
42 > collect2 (from gcc) calls ld. I'm using my "stock" gcc build and its working for me.
43
44 I understand you've built gcc-4.3.1 yourself without any patches,
45 not configuring '--with-ld', right?
46 Actually I did have problems[1] to bootstrap Prefix on Fedora/RedHat, where
47 the host-gcc also does search for "ld" using ${PATH} environment variable.
48
49 [1] http://prefix-launcher.svn.sourceforge.net/viewvc/prefix-launcher?view=revision&revision=351
50
51 >>>> Although runpath search is affected by LIBPATH, I'm just fine with that.
52 >>>> This is the outcome of using "-L" and "-l" linker flags together.
53 >>> I thought this was one of your objectives based on the fact that java sets LIBPATH
54 >>> to something weird and it breaks everything.
55 >> Nope. The problem with LIBPATH set by java was that there is nothing
56 >> like "soname". Iff my binary had searched for the /file/ "libiconv.so.2"
57 >> (either archive or not) instead of "libiconv.a(libiconv.so.2)", even with
58 >> LIBPATH set to "/usr/lib" it would not have found "/usr/lib/libiconv.a"
59 >> (without "libiconv.so.2" member), but continued along LIBPATH + runpath
60 >> until it found the "libiconv.so.2" file in its usual place.
61 > Hmmm... ok. I had forgotten that detail.
62
63 Yes, a detail - but a really important one for package managers.
64
65 >>>> Seems we have to agree on some terms to be used first.
66 >>> Yes.
67 >>> I like "fixed" for entries not affected by runtime search.
68 >> "fixed" = "hardcoded" (see above).
69 >>> The other tact would be to note that PATH is either empty or not.
70 >>> "A path dependency with no path" or "a dependency with a path" ?
71 >> Which "PATH" ("path") do you refer to here that can be either empty or not?
72 >
73 > In the dump -H output above, there is a column called PATH. That PATH. I apologize for being
74 > so consistently vague.
75
76 Ah, ok. But what is a "path dependency with no path" ?
77
78 >>>> OTOH, when the /absolute/path/to/the/library.so found at linktime is hardcoded into
79 >>>> the resulting binary, installing into DESTDIR is broken - which is a prerequisite
80 >>>> for package managers like portage to work properly.
81 > Does the package (need to) work from the /image area or is this
82 > just a temporary place used to create the tar file? In particular,
83 > what about paths hard coded into the binaries? (Not the
84 > paths in the binary's header but just paths hard coded in the code
85 > like where to find my lisp files, etc. I know that *usually* there are
86 > options to change them but there is still some default set at compile
87 > time.
88
89 Nope, there is no need for anything to work from the /image area.
90 This is just a temporary location for the package manager to
91 identify/track/ship the files a package does install.
92
93 >> $ cd "/image"
94 >> During step 3, the shared library gets installed as "/staging/final/lib/library.so".
95 >> Relinking "mybinary", the linker has to read that file, while encoding "/final/lib"
96 >> (without "/staging") into "mybinary" as the search path for "library.so".
97 >
98 > Shoot... you lost me. I think maybe /staging is the same as /image above?
99
100 Yes, "/staging" is the same as "/image" - apparently I've missed
101 a few when replacing "/staging" by "/image". Sorry for confusion.
102 But that's not the reason you got lost, is it?
103
104 > One question: with each of your experiments, do you dump out the
105 > binary's "header" with dump -H?
106
107 Yes, at least usually.
108
109 > The reason I ask is I would expect
110 > linking with an import file basically just put that piece, the #!<whatever>
111 > into the binary's header at link time and then what happens at run
112 > time is the same as if you had linked against a library.
113
114 Basically yes.
115 The difference is that the values from "#! PATH/BASE(MEMBER)" are stored as-is
116 into the binary's "Import File Strings" (as PATH BASE MEMBER), independent of
117 how that Import File was specified on the linker's commandline, while for real
118 shared objects it does make a difference how to specify them there.
119
120 > I remember toying with the import file inside the archive (and getting
121 > frustrated at the lack of documentation) but I can't remember what
122 > I found.
123
124 Agreed, even with the ld(1) manpage it is quite hard to get an idea of how to do
125 it right. It took me years(!) of playing around/staring at that manpage/reading
126 online docs and howto's/sleepless nights, until I figured out how I want to do
127 "shared libraries" with "soname" (AIX does not have these terms) here.
128
129 /haubi/
130 --
131 Michael Haubenwallner
132 Gentoo on a different level

Replies

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