On 9/11/13, Peter Rosin <p...@lysator.liu.se> wrote: > On 2013-09-10 16:10, Peter Rosin wrote: >> On 2013-09-10 15:56, Ozkan Sezer wrote: >>> OK then, I'll keep an eye on mails from this list. >>> >>> (On an irrelevant note, the archive pages at >>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html >>> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html >>> doesn't list any mails from me, but the ones from you from this thread >>> are there, so I don't know whether any of the mails I send arrive at >>> the list..) >> >> That's strange, but you are correct in that all mails I have >> received from you have been coming directly too me, and none have >> arrived through the list. Maybe they are stuck in moderation, but >> I don't know the details of that??? >> >> Anyway, I managed to dig up at least some background, see this thread >> >> http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html > > More background [1], [2]: > > Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2, > so that it nowadays automatically appends -print-multi-os-directory > for the applicable directories. I.e. it should no longer be necessary > for libtool to append a second ../lib64 when GCC has already done so. > Also, the multi-os appending crap seems to have been added specifically > for early (arguably broken) bi-arch enabled GCCs that printed -m32 > directories even though -m64 was the default. So, my conclusion is > that we want any libtool magic to affect -print-search-dirs output from > contemporary GCCs as little as possible, while continuing to append > the -print-multi-os-directory for the legacy case. > > The thing to look out for could be if any of the -print-search-dirs > ends with /$lt_multi_os_dir and use that as an indicator that we have > a sufficiently new GCC, and all -print-search-dirs should be left as > is (we should probably continue prune those that don't exist, though). > > I have attached a version that implements the above idea.
I can confirm that with this applied to libtool-git, I can build a dll using cross-toolchains on linux. The `libtool --config` output for sys_lib_search_path_spec contains, - for a i686-pc-mingw32 toolchain with gcc-3.4.5: "/usr/local/cross-win32/i686-pc-mingw32/lib /usr/local/cross-win32/lib /usr/local/cross-win32/usr/lib " - for a i686-w64-mingw32 toolchain with gcc-4.5.4: "/opt/W32_180676/lib/gcc /opt/W32_180676/i686-w64-mingw32/lib32 /opt/cross_win32/mingw/lib32 /opt/W32_180676/i686-w64-mingw32/lib /opt/cross_win32/mingw/lib " - for an x86_64-w64-mingw32 toolchain with gcc-4.5.4: "/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 /opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib " Thanks for working on this. > I feel > pretty good about that one actually, but would still like some > feedback from someone more familiar with multilib... > > Or should we just ditch support for those early, arguably broken, > bi-arch GCC versions and start trusting -print-search-dirs > unconditionally??? > > Cheers, > Peter > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425 > [2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html > -- O.S. _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
