Re: link-order.at problem on Cygwin

[Ralf Wildenhues]

Hi Peter,

* Peter Ekberg wrote on Tue, Sep 20, 2005 at 03:25:01PM CEST:
> 
> The recent change to bug out when the exit code is non-zero [1]
> uncovered a silent failure on Cygwin (an MinGW I suppose) in
> the link-order.at test.
> 
> The problem is as follows:
> 
> 1. liba is built with an a_old symbol.
> 2. liba is installed in old/lib (dll installed in old/bin).
> 3. A new liba is built with an a_new symbol.
> 4. liba is installed in new/lib (dll installed in new/bin).
> 5. main_old is linked against old/lib/liba
> 6. main_old is executed, but finds the new liba dll.
> 7. crash and burn
> 
> The reason it finds the new liba dll is that it is left behind
> in the src/.libs dir along with the freshly built main_old.exe.
> main_old.exe of course finds this dll as it is in the same dir
> as the exe itself.
> 
> Is the intension of the test to spot this problem, or can I
> write a patch that builds the liba dlls somewhere else so that
> the last built liba isn't in the same dir as the test exes?

If in doubt: the test should make sure the original bug is fixed:
http://lists.gnu.org/archive/html/libtool-patches/2005-04/msg00032.html

So this reveals that we are testing something slightly different:
we install both liba versions before linking against them.  What we
should be doing according to the bug report: link and install the old
version, then `$LIBTOOL --mode=clean' the old library, link the new
library, link the program, execute the uninstalled, install both,
execute again.

Then we should make sure that, if we undo the patch from Alexandre
that was installed, the test fails.  Actually, come to think of it,
we should make sure it fails even without the EGREP test.

If you haven't fixed this already,  :-)
I can probably look into it sometime.

Cheers,
Ralf