<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 9, 2011, at 4:33 PM, Michael Haubenwallner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Perry,<br><br>On 02/09/11 17:47, Perry Smith wrote:<br><blockquote type="cite">Lets start over. I don't think I'm making any progress but I'll give it one last go.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Here is the output of dump -H of my installed ruby:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">/usr/local/rvm/rubies/ruby-1.9.1-p378/bin/ruby:<br></blockquote><blockquote type="cite"> ***Import File Strings***<br></blockquote><blockquote type="cite">INDEX PATH BASE MEMBER <br></blockquote><blockquote type="cite">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 <br></blockquote><blockquote type="cite">1 librtl.a shr.o <br></blockquote><blockquote type="cite">2 /usr/lib libc.a shr.o <br></blockquote><blockquote type="cite">3 /usr/lib libpthread.a shr_comm.o <br></blockquote><blockquote type="cite">4 /usr/lib libpthread.a shr_xpg5.o <br></blockquote><blockquote type="cite">5 /usr/local/rvm/rubies/ruby-1.9.1-p378/lib libruby.so <br></blockquote><br>Is this with our without your intervention in ruby's build process and/or toolchain setup?<br></div></blockquote><div><br></div>This is after my toolchain changes.</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">Except for librtl.a, there are no relative paths anywhere. That is one of my objectives (and your's I believe).<br></blockquote><br>There is no "relative" path by the usual means of "relative" /anywhere/ here,<br>there are only "absolute" paths here - a "relative" path does not start with "/".<br>However, librtl.a is subject to "runpath search", while the others are not<br>due to "hardcoded" (unsure about this term) paths - but still "absolute"<br>paths everywhere.<br><br>Anyway - taking "relative" as "with runpath search", and "absolute" as<br>"without runpath search" or even "hardcoded" here now.<br></div></blockquote><div><br></div>Yea. I need to use better terms. but I think you are following me. I'm</div><div>using the same term to mean two different things.</div><div><br></div><div>In the 0'th entry above, there are no entries like "." (so in that case, that term "relative path"</div><div>or "absolute path" is correct.)</div><div><br></div><div>The 1st entry is what I was calling "relative" but as you point out, that isn't the right term.</div><div>"affected by run path search" is too long for me. :-)</div><div><br></div><div>The 2nd through 5th items are those I was calling "absolute" but really they should be</div><div>called "not affected by run path search". Perhaps "fixed" in this case would work? </div><div>non-LIBPATH-able?</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">It is using /usr/local/rvm/rubies/ruby-1.9.1-p378/lib/libruby.so .<br></blockquote><blockquote type="cite">If I move that to somewhere else, like <br></blockquote><blockquote type="cite">/usr/local/rvm/rubies/ruby-1.9.1-p378/lib/other/libruby.so<br></blockquote><blockquote type="cite">ruby does not work and setting LIBPATH does not fix the problem.<br></blockquote><br>Of course, due to the hardcoded paths no runpath search is performed.<br><br><blockquote type="cite">Thus, for an object (I'll use the word "object" to mean shared object or an executable)<br></blockquote><br>Usually, "binary" is the term to be used here, but ok...<br><br><blockquote type="cite">that is linked without only absolute paths, it will not work in the directory that it is built in.<br></blockquote><br>Let me grasp that: "without only absolute" paths "it will not work" where built.<br>Isn't this a typo and should read "*with* only absolute" ?<br></div></blockquote><div><br></div>Yes. typo. sorry. I really do go back and proof read my emails.</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">In the case of ruby, it builds the library and executable in the same pass.<br></blockquote><blockquote type="cite">I think this is typical.<br></blockquote><br>Yep.<br><br><blockquote type="cite">If you plan to run "make test" or "make check" (different packages call it different things)<br></blockquote><blockquote type="cite">before the install, you have a problem.<br></blockquote><br>Only if the paths are hardcoded - but this is unusual.<br><br><blockquote type="cite">The way I solved that problem is to allow the object to have relative paths (or no path)<br></blockquote><blockquote type="cite">before it is installed, do the "make check",<br></blockquote><br>How exactly did you touch either the build process or the toolchain setup to "allow" that?<br></div></blockquote><div><br></div><div>I put my ld in /usr/local/aixbin/ld and I put /usr/local/aixbin as the first element of PATH.</div><div>So my ld gets called instead of the real ld. My ld monkeys with things.</div><div><br></div><div>After everything is installed, I go back through with "rl". I did this by hand at the present time.</div><div>In the limited case that I'm experimenting with, everything is installed off in a directory that</div><div>is just the new ruby install. I can do a find for the binary files and then call rl on them and it</div><div>will make the changes.</div><br><blockquote type="cite"><div><br><blockquote type="cite">then either fix the object just before install or fix it just after the install.<br></blockquote><blockquote type="cite">I choose to fix it just after the install with "rl".<br></blockquote><br>Same here: How to touch the build process or the toolchain setup to get "rl" used?<br></div></blockquote><div><br></div><div>See above.</div><br><blockquote type="cite"><div><br><blockquote type="cite">I don't see how you can have an object that has only absolute paths after it is installed<br></blockquote><blockquote type="cite">*and* is able to be used before the install so that "make check" or "make test" can be run<br></blockquote><blockquote type="cite">(except by some weird chroot tricks but no one wants to go down that path).<br></blockquote><br>Yep, that doesn't work.<br><br><blockquote type="cite">Lets pause here and see if we can come to an agreement on these two items.<br></blockquote><blockquote type="cite">1) objets have only absolute paths after they are installed<br></blockquote><br>Still not clear to me:<br>Do you actually /prefer/ hardcoded paths (without runpath search)? Why?<br><br>Although runpath search is affected by LIBPATH, I'm just fine with that.<br>This is the outcome of using "-L" and "-l" linker flags together.<br></div></blockquote><br>I thought this was one of your objectives based on the fact that java sets LIBPATH</div><div>to something weird and it breaks everything.</div><div><br></div><div><blockquote type="cite"><div><br>It is unusual to use hardcoded path (without runpath search), which is the<br>result of using /absolute/path/to/the/library.so instead of "-L" and "-l".<br><br>So when ruby's build system uses /absolute/path/to/the/library.so, you should<br>try to fix that to use "-L" and "-l", as well as "-blibpath" eventually instead.<br></div></blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite">2) The "make check" must work before package is installed.<br></blockquote><br>Yep, agreed on this one.<br><br>Seems we have to agree on some terms to be used first.<br></div></blockquote><div><br></div><div>Yes. </div><div><br></div><div>I like "fixed" for entries not affected by runtime search.</div><div><br></div><div>The other tact would be to note that PATH is either empty or not.</div><div><br></div><div>"A path dependency with no path" or "a dependency with a path" ?</div><div><br></div><div>"binary" instead of "object" sounds better to me.</div><br><blockquote type="cite"><div><br>What else to say:<br>When libtool knows for a platform that linking libraries results in hardcoded<br>paths, or there is no such thing like LIBPATH environment variable to temporarily<br>override the runpath, it actually /does/ "relink" the binaries during installation.<br></div></blockquote><div><br></div>I understood that part -- but</div><div><br><blockquote type="cite"><div>OTOH, when the /absolute/path/to/the/library.so found at linktime is hardcoded into<br>the resulting binary, installing into DESTDIR is broken - which is a prerequisite<br>for package managers like portage to work properly.<br></div></blockquote><div><br></div>Didn't understand this part. In particular, from the comma to the end ", installing ..."</div><div><br><blockquote type="cite"><div><br>/haubi/<br>-- <br>Michael Haubenwallner<br>Gentoo on a different level<br><br></div></blockquote></div><br></body></html> |
