[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool woes

From: Ozkan Sezer
Subject: Re: libtool woes
Date: Tue, 17 Sep 2013 10:50:43 +0300

On Wed, Sep 11, 2013 at 1:32 PM, Ozkan Sezer <address@hidden> wrote:
> 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
>>>> 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
>> 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]
>> [2]

Any chance that this patch, or a patch that fixes bug #15321 [1],
gets applied any time?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]