[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool woes
From: |
Ozkan Sezer |
Subject: |
Re: libtool woes |
Date: |
Tue, 10 Sep 2013 13:52:15 +0300 |
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.
- Re: libtool woes, (continued)
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes,
Ozkan Sezer <=
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Ozkan Sezer, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/10
- Re: libtool woes, Peter Rosin, 2013/09/11
- Re: libtool woes, Ozkan Sezer, 2013/09/11
- Re: libtool woes, Ozkan Sezer, 2013/09/17