Re: libtool "no symlinked libs" patch

[Jacob Meuser]

On Tue, Nov 29, 2005 at 12:15:09AM +0900, Peter O'Gorman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ralf Wildenhues wrote:
> 
> | The way I see it, there are two possible ways out:
> |
> | 1) Move all paths to uninstalled libraries (in the correct order) before

the patch does put them in the order they are encountered.  my first
attempt reversed them.

> | all other path specs.  This is pretty much in the spirit of the patch
> | you posted in the other mail to the ports list.  It would need some
> | cleanup, and should probably be conditionalized on $hardcode_direct=yes.

well, it could be a little cleaner, I suppose.  it's mostly
cut-n-pasted from existing libtool code.

> | Also, I think I would move the flags right when I encounter the libs,
> | not mangle them afterwards.  (That would save us from needing .libs aka
> | $objdir as a criterion here.)  Lemme see..

that was my first thought as well, but, I hard a really hard time
trying to figure out exactly where this happens, and if $deplibs
is in the right order at that time.  seems they get reversed and then
rereversed at least once.  so I went with waiting until the very end,
when I could be sure $deplibs would not be changed any more.

> | This approach comes with the minor danger that other libraries living in
> | those directories may be picked up; this _should_ not hurt, as all those
> | paths should be within the same package, or package tree, and the tree
> | should contain only desired libraries.
> 
> This should be fine, I doubt that it even needs to be conditionalized on
> anything. If there are libraries in the build directories that the linker
> must not find then there is something seriously wrong with the package.

I thought about that too and came to the same conclusion.  I don't
think there is much that can be done by libtool to fix such a
situation.

-- 
<address@hidden>