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
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
