On 9/10/13, Ozkan Sezer <seze...@gmail.com> wrote: > On 9/10/13, Peter Rosin <p...@lysator.liu.se> 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. _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
