libtool
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]