Re: libtool woes

[Peter Rosin]

On 2013-09-10 11:50, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin <address@hidden> wrote:
>> 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 2.4.2.393-5d4a 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 2.4.2.393-5d4a, 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...
> 
> What changed between 1.5 and 2.x so that 1.5 used to work fine but
> 2.x seems to pick something to its liking?  Where to look for in
> libtool.m4?

A bunch of things? :-]

Anyway, I could reproduce locally after I did:

        mkdir /usr/x86_64-w64-mingw32/sys-root/mingw/lib64

With that dir in place, libtool no longer finds any import libraries,
and I get the same error as you. I could work around it with

        make LDFLAGS="-L/usr/x86_64-w64-mingw32/sys-root/mingw/lib"

but that's hardly satisfactory...

I can note that, on at least my system, that multi-os-dir loop does
no good at all. The only thing it accomplishes is to append /../lib64
to directories already ending with .../lib64, and to potentially mess
up directories that are supposed to end with .../lib

So, what good does that loop do? Work around broken multilib compilers
printing the wrong thing in -print-search-dir, or what?

Anyway, one safe solution would be to not try to append /$lt_multi_os_dir
if the resulting path is already present in the search path, which happens
to be the case here, you have both

        /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/

and

        /opt/W64_180676/bin/../../cross_win64/mingw/lib/

So, speculatively appending /../lib64 to the second one seems detrimental
to me. Not that the check is not going to be fun to implement, with all
relative directories to consider, but it's at least an idea that seems
safe to me...

Cheers,
Peter