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 |