[Top][All Lists]

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

Re: libtool woes

From: Peter Rosin
Subject: Re: libtool woes
Date: Tue, 10 Sep 2013 11:43:35 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 2013-09-10 11:26, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin <address@hidden> wrote:
>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin <address@hidden> wrote:
>>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>>>> On 9/10/13, Peter Rosin <address@hidden> wrote:
>>>>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>>>>>> Tell me if you need anything else.
>>>>>> Let's focus on the libtool if that's ok with
>>>>>> you.
>>>>>> Can you provide the output from "libtool --config" and
>>>>>> config.log? I'm not set up to easily duplicate your
>>>>>> environment...
>>>>>> Cheers,
>>>>>> Peter
>>>>> Attached ./libtool --config output after configuration. Attached
>>>>> config.log.
>>>> Your error messages indicate that libtool cannot find any files
>>>> matching the various things associated with -lole32 (and other
>>>> w32 libraries). I.e. it's not that the any files found are not
>>>> considered good enough, it's that libtool doesn't find them
>>>> at all. So, the dlltool --identify code path is in all likelihood
>>>> perfectly fine, it's just that nothing is being fed to dlltool
>>>> in the first place.
>>>> So, something seems to be fishy with your library search path.
>>>> I notice this in your libtool --config:
>>>> # Compile-time system search path for libraries.
>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "
>>>> Do you have any libole32.a (or something such) in any of those
>>>> places? If not, where are they? (and why didn't libtool pick
>>>> that up when it did $host-gcc --print-search-dirs?)
>>> You are on the right track, and I think my new msg hasn't arrived yet.
>> The messages crossed each other, yes. :-)
>>> See the attached new file libtool--config-1.5.out which is the output
>>> if I use libtool-1.5, and yes the the important difference is
>>> sys_lib_search_path_spec. With, it is:
>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>> "
>>> With 1.5, it is:
>>> sys_lib_search_path_spec="
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../lib/gcc/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
>>> i.e. <topdir>/x86_64-w64-mingw32/lib, but 2.4 is not doing it and
>>> using <topdir>/x86_64-w64-mingw32/lib64 instead for reasons
>>> unfathomable to me. <topdir>/x86_64-w64-mingw32/lib64 does exist,
>>> but it only holds gcc's libs, and as a result, the necessary libs
>>> aren't found.
>> So, what output do you get from
>>      x86_64-w64-mingw32-gcc --print-search-dirs
>> I get:
>> $ x86_64-w64-mingw32-gcc --print-search-dirs
>> install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
>> programs:
>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
>> libraries:
>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/
> Mine says:
> $ x86_64-w64-mingw32-gcc --print-search-dirs
> install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
> programs: 
> =/opt/W64_180676/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/
> libraries: 
> =/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/:/opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/:/opt/W64_180676/bin/../../cross_win64/mingw/lib/
> In a rather hopeless attempt to fix this, I tried browsing libtool.m4
> searching places for sys_lib_search_path_spec and the place it is
> generated, I noticed a lot of :
> case $host_os in
>  mingw*)
> [stuff]
> ... which doesn't seem right because they seem to be trying to deal
> with dosisms but not thinking about a possibility of cross-toolchain
> running on unix.  Still found no solutions..

All the action is at the top of the _LT_SYS_DYNAMIC_LINKER macro, inside
if test yes = "$GCC"; then. MinGW has always been an oddball, since the
native MinGW tools make heavy use of those dosisms. The path separator
differences are mostly handled by assuming that any path looking like a
dosy path *is* a dosy path (e.g. if it starts with "<letter>:"), and
that highly unlikely that you'd have a semicolon in a unixy path (which
would lead to other problems). IOW, libtool tries to handle both the
dosy (native) case and the unixy (cross) case.

Anyway, I think your trouble is caused by the multi-os-dir loop just
after the -print-search-dir segment. You already hinted at that, but I
don't know what to do about it though...


reply via email to

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