[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 15:41:54 +0300 |
On 9/10/13, Ozkan Sezer <address@hidden> wrote:
> 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?
>
OK, I sent a message to bug-libtool about this (hopefully it arrives there.)
--
O.S.
- Re: libtool woes, (continued)
- 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
- Re: libtool woes, Peter Rosin, 2013/09/17
- Re: libtool woes, Peter Rosin, 2013/09/17
- Re: libtool woes,
Ozkan Sezer <=
- Re: libtool woes, Ozkan Sezer, 2013/09/10
Re: libtool woes, Ozkan Sezer, 2013/09/10