Re: libtool woes

[Peter Rosin]

On 2013-09-10 12:25, Ozkan Sezer wrote:
> On 9/10/13, Ozkan Sezer <address@hidden> 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?
>>
> 
> OK, see the diff below (also attached in case it gets mangled):
> 
> --- libtool.m4~
> +++ libtool.m4
> @@ -2213,11 +2213,11 @@
>  if test yes = "$GCC"; then
>    case $host_os in
>      darwin*) lt_awk_arg='/^libraries:/,/LR/' ;;
>      *) lt_awk_arg='/^libraries:/' ;;
>    esac
> -  case $host_os in
> +  case $build_os in
>      mingw* | cegcc*) lt_sed_strip_eq='s|=\([[A-Za-z]]:\)|\1|g' ;;
>      *) lt_sed_strip_eq='s|=/|/|g' ;;
>    esac
>    lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg |
> $SED -e "s/^libraries://" -e $lt_sed_strip_eq`
>    case $lt_search_path_spec in
> @@ -2264,11 +2264,11 @@
>    if (lt_foo != "") { lt_freq[[lt_foo]]++; }
>    if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
>  }'`
>    # AWK program above erroneously prepends '/' to C:/dos/paths
>    # for these hosts.
> -  case $host_os in
> +  case $build_os in
>      mingw* | cegcc*) lt_search_path_spec=`$ECHO "$lt_search_path_spec" |\
>        $SED 's|/\([[A-Za-z]]:\)|\1|g'` ;;
>    esac
>    sys_lib_search_path_spec=`$ECHO "$lt_search_path_spec" | $lt_NL2SP`
>  else
> @@ -2416,10 +2416,22 @@
>        sys_lib_search_path_spec="$sys_lib_search_path_spec /usr/lib/w32api"])
>        ;;
>      mingw* | cegcc*)
>        # MinGW DLLs use traditional 'lib' prefix
>        soname_spec='$libname`echo $release | $SED -e
> 's/[[.]]/-/g'`$versuffix$shared_ext'
> +      sys_lib_search_path_spec=`$CC -print-search-dirs | grep
> "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
> +      if echo "$sys_lib_search_path_spec" | [grep ';[c-zC-Z]:/'
>> /dev/null]; then
> +        # It is most probably a Windows format PATH printed by
> +        # mingw gcc, but we are running on Cygwin. Gcc prints its search
> +        # path with ; separators, and with drive letters. We can handle the
> +        # drive letters (cygwin fileutils understands them), so leave them,
> +        # especially as we might pass files found there to a mingw objdump,
> +        # which wouldn't understand a cygwinified path. Ahh.
> +        sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" |
> $SED -e 's/;/ /g'`
> +      else
> +        sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" |
> $SED  -e "s/$PATH_SEPARATOR/ /g"`
> +      fi
>        ;;
>      pw32*)
>        # pw32 DLLs use 'pw' prefix rather than 'lib'
>        library_names_spec='`echo $libname | sed -e 's/^lib/pw/'``echo
> $release | $SED -e 's/[[.]]/-/g'`$versuffix$shared_ext'
>        ;;
> 
> 
> The first two hunks about only correctness and don't affect my thing.

They will break libtool for those using native MinGW compilers from
with Cygwin or with Wine. Yes, some people do that sort of thing.

> However, the last third hunk is the heart of it:  adding that fixes
> the issue.  That part was present in 2.2.6 but was removed in 2.2.8
> and later. What was the reason? (I couldn't find in the history using
> gitweb, but didn't try hard enugh either..)

That last hunk will evade the multilib loop by redoing the -print-search-dirs
thing one more time after that loop. However, it is severely broken on
native MinGW [1] and can definitely not be added as is. Sorry.

[1] http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00052.html

Cheers,
Peter