[Top][All Lists]

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

Re: RFA: libtool.m4

From: JonY
Subject: Re: RFA: libtool.m4
Date: Fri, 01 May 2009 17:47:23 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

On 5/1/2009 17:10, Kai Tietz wrote:
2009/5/1 Ralf Wildenhues<address@hidden>:
* 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.


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)?

The bug is pretty easy to reproduce. You need just gcc's source tree
and to build a cross-compiler for x86_64-pc-mingw32 target. You will
notice that libstdc++ and libobjc aren't build as shared libraries for
this target. On close investigation you will see that this reasoned by
the checks in libtool (described above).

The bug I found might be the same bug as the Kai's, but I'm not sure.

I noticed this when cross compiling mpg123 (build system is i686-pc-mingw32, host system is x86_64-pc-mingw32). The provided build script automatically attempts to build the package with various configuration (configure; make; make install), among them shared/static builds.

While using libtool to link the libmpg123 dll, libtool incorrectly determines libwinmm.a as a static archive (its really an import library to a system dll), and so refuses to produce a dll.

A working x86_64-pc-mingw32 toolchain is needed to reproduce it.

I think I know what and how to fix things, but I also want to
make sure that we don't trip over a similar bug again in the
future, so I need a way to (allow you to) reproduce it (on
your system).

The check would be to run for mingw targets this check and if shared
library support isn't present this would be the failure. Sadly I have
no experience how to add such a test to libtool, so I trust in you
knowledge here.

reply via email to

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