multilib2 patch (was: another 1.5 release)

[Ralf Wildenhues]

* 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.