Re: libtool woes

[Peter Rosin]

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

0001-libtool-trust-print-search-dirs-from-recent-GCC.patch
Description: Text Data