* JonY wrote on Wed, Apr 29, 2009 at 12:53:54PM CEST:
On 4/29/2009 15:26, Kai Tietz wrote:
2009/4/28 Ralf Wildenhues<address@hidden>:
* Kai Tietz wrote on Tue, Apr 28, 2009 at 02:29:12PM CEST:
In the libtool.m4 in function _LT_CHECK_MAGIC_METHOD the current check
for mingw doesn't treat the x64 proper.
It checks for 'file_magic file format pei*-i386(.*architecture:
i386)?', what is right for 32-bit mingw, but for 64-bit version this
string needs to be changed to something like 'file_magic file format
pei*(.*architecture: i386)?'
I did the libtool testsuite run for w64 target and found no serious
issues (as I expected). But the underlying issue isn't tested in the
suite at all my initial post is pointing on. The problem is that the
pattern used (and so also in libtool itself) for detection if a dll
(windows shared object) is generated is wrong.
So, can you devise a short example, or ideally even a testsuite addition
to git Libtool that exposes this issue? Alternatively, describe the
situation in which you encountered it.
in aclocal.m4 there is the line
'lt_cv_deplibs_check_method='file_magic file format
pei*-i386(.*architecture: i386)?'
which doesn't fit for 64-bit dlls.
lt_cv_deplibs_check_method='file_magic file format
pei*-(i386|x86_64)(.*architecture: i386)?'
I am confused on the following 2 functions work.
deplibs_check_method
func_win32_libid
The shell function tries to differentiate between static libraries on
the one hand, and import libraries and DLLs on the other. It does so
by trying out a couple of heuristics.
The deplibs_check_method is just a hint to libtool on which method to
use in order to search for deplibs, that is, library dependencies.
Sorry my shell scripting was never good to begin with. So here are some
possibly helpful info.
The information that I would like to have is the following:
Kai has reported some kind of bug. Please tell me how you
noticed it. What do I need to do to reproduce it (you may
assume for the moment that I had a w64 system to test with)?