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: Perry Smith <pedzsan@...>
Subject: Re: AIX linking adventure
Date: Wed, 9 Feb 2011 18:57:29 -0600
<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. &nbsp;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"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;***Import File Strings***<br></blockquote><blockquote type="cite">INDEX &nbsp;PATH &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BASE &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MEMBER &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br></blockquote><blockquote type="cite">0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/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 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br></blockquote><blockquote type="cite">1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;librtl.a &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;shr.o &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br></blockquote><blockquote type="cite">2 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/usr/lib &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;libc.a &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;shr.o &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br></blockquote><blockquote type="cite">3 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/usr/lib &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;libpthread.a &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;shr_comm.o &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br></blockquote><blockquote type="cite">4 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/usr/lib &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;libpthread.a &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;shr_xpg5.o &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br></blockquote><blockquote type="cite">5 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/usr/local/rvm/rubies/ruby-1.9.1-p378/lib libruby.so &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<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. &nbsp;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. &nbsp;I need to use better terms. &nbsp;but I think you are following me. &nbsp;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&nbsp;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". &nbsp;Perhaps "fixed" in this case would work? &nbsp;</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. &nbsp;typo. &nbsp;sorry. &nbsp;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. &nbsp;My ld monkeys with things.</div><div><br></div><div>After everything is installed, I go back through with "rl". &nbsp;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. &nbsp;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. &nbsp;</div><div><br></div><div>I like "fixed" for entries not affected by runtime search.</div><div><br></div><div>The other tact would&nbsp;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. &nbsp;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>
Replies:
Re: AIX linking adventure
-- Michael Haubenwallner
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
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:
Re: AIX linking adventure
Next by date:
Re: AIX linking adventure


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.