[Top][All Lists]

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

Re: MinGW/Cygwin wrapper bug

From: Bob Friesenhahn
Subject: Re: MinGW/Cygwin wrapper bug
Date: Tue, 4 Dec 2007 15:30:25 -0600 (CST)

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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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