Re: libtool woes

[Ozkan Sezer]

On 9/11/13, Peter Rosin <address@hidden> 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.