Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin <address@hidden> wrote:
[...]
>> @@ -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'
>>        ;;
>>
>>
[...]
>> 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
>

That effectively cripples libtool for cross-compilers. Can the behavior
be refined instead?  Can you contact Charles Wilson about this?

--
O.S.