Re: libtool woes

[Ozkan Sezer]

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
>>>> 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