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. -- <[EMAIL PROTECTED]>
