* Daniel Reed wrote on Fri, Dec 03, 2004 at 05:20:36PM CET: > On 2004-12-03T08:33+0100, Ralf Wildenhues wrote: > > ) Technical issues with the patch: > ) - Why is, after your patch, $found set twice before searching (is there a > ) reason for this)? > > Libtool seems to use the state "$found = no" (the literal check "$found != > yes") for the dual use of failure and success with non-Libtool library. I > added a third state of "$found = unknown" to mean failure "so far" in the > search and kept "$found = no" to mean its original meaning. Libtool never > checks for "$found = no", only "$found != yes", so this should not cause a > behavior change outside of the search code.
After a little testing.. ..maybe it's not the right way to do it after all.. :( Setup: I have a custom-built gcc in a nonstandard directory on a x86_64 with linux (fedora core 3). `g++' iself is 64bit (which shouldn't matter at all), but it should be able to produce 32 and 64 bit code.[1] Before as well as after your change, the first part of the search algorithm finds the libstdc++.la which belongs to the 32bit version and shortcuts your second part. Linking tests/tagdemo/libfoo.la fails happily. I *can* get it to work if I put the -print-file-name stuff at the beginning of the search.. This needs further testing (besides putting the actual -print-file-name logic into libtool.m4), I fear. Help wanted. Regards, Ralf [1] The fact that it's a development version shouldn't matter in this regard, I think. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
