Re: libtool woes

[Ozkan Sezer]

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

--
O.S.

4x.diff
Description: Binary data