Re: MinGW/Cygwin wrapper bug

[Bob Friesenhahn]

On Tue, 4 Dec 2007, Ralf Wildenhues wrote:

> * Bob Friesenhahn wrote on Tue, Dec 04, 2007 at 10:09:25PM CET:
> > I am not sure how to wrap it up in a test.  The problem is not an
> > obscure error since it is always present.  I am surprised that I am
> > the only one who has reported the problem.
>
> OK so here's a try of mine.  Can you confirm that this exposes the bug,
> i.e., the last line prints 1 instead of 0?
>
> Or is it rather that you have a problem at link time?  Then the last
> mode=link should fail iff, on the line marked XXX, `int a' is replaced
> with `int b'.
>
> Which of the two suspected setups is the failing one?

To make things more clear, the problem is entirely which DLL is used 
when the wrapper script/program is executed.  Libtool builds a correct 
DLL, but when 'make check' is executed and the installation 'bin' 
directory is in the executable search path (PATH) then a similar DLL 
from the installation 'bin' directory is used rather than the one that 
libtool just built.  Unless DLL interfaces have been removed since the 
previous install, the user is not likely to immediately (if ever) 
notice that the wrong DLL is used for testing.  This sort of bug 
causes much frustration on the part of developers.

Since DLLs are installed in the installation 'bin' directory, it is 
common/normal for PATH to also include the installed DLL.

In order to avoid this problem, PATH must be populated to include any 
necessary .libs directories prior to the already existing PATH.  PATH 
is as close as it comes to LD_LIBRARY_PATH under Windows.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/