bug-libtool
[Top][All Lists]
Advanced

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

Re: RFA: libtool.m4


From: Kai Tietz
Subject: Re: RFA: libtool.m4
Date: Fri, 1 May 2009 11:10:13 +0200

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

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

> 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.

> Thanks,
> Ralf
>

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination




reply via email to

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