On Wed, Sep 11, 2013 at 1:32 PM, Ozkan Sezer <seze...@gmail.com> wrote: > 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 >> >
Any chance that this patch, or a patch that fixes bug #15321 [1], gets applied any time? -- O.S. [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15321 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool