bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: link-order.at problem on Cygwin


From: Peter Ekberg
Subject: RE: link-order.at problem on Cygwin
Date: Tue, 20 Sep 2005 16:02:45 +0200

* Peter Ekberg wrote on Tuesday, September 20, 2005 15:25 CEST:

That's me. Changing list to libtool-patches.

> Hi!
> 
> 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?
> 
> [1]
>
http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00098.html

Oh, what the hell, here's the patch. Good to go?

        * tests/link-order.at: Build the variants of liba
        and libb in another dir so that the test executables
        are not picking up the dlls from the current dir on
        Cygwin and MinGW.

Cheers,
Peter

Attachment: head-build-link-order-libs-elsewhere.patch
Description: head-build-link-order-libs-elsewhere.patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]