[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multilib improvement?
From: |
Ralf Wildenhues |
Subject: |
Re: multilib improvement? |
Date: |
Tue, 24 Oct 2006 22:24:25 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
* Peter O'Gorman wrote on Sat, Oct 21, 2006 at 02:11:19PM CEST:
> On Oct 21, 2006, at 8:52 PM, Ralf Wildenhues wrote:
> >Do you have better ideas?
>
> No, the way I "tested" it was to run ./configure; make with CC set to
> gcc -m32 and gcc -m64 on a few systems and look at
> sys_lib_search_path_spec manually after each run to see if it looked
> sane. Your patch is better than that :)
Hmm. I was thinking of walking each of those directories, picking a
random file matching each of *.la *.a *.$shrext and trying to link
against them with -l without a -L path. For added hardness one could
first try to extract a symbol from the library in question and refer to
that in the main program.
I do fear however that this will break on some systems. Maybe it's
still worth doing (with singling out those systems then). Have I missed
anything obvious? Do you think the maintenance of it may be high?
> >And of course the patch is missing a NEWS addition, this having been
> >a bug that bothered many people.
> >
> >OK to apply (NEWS also to branch-1-5)?
> >I haven't had a chance to test your actual patch yet, by the way.
>
> Looks okay on visual inspection. Please apply.
Done, thanks.
> Would appreciate testing of the patch too when you get around to it.
Still todo. I think there is at least one problematic scenario: Say
/usr/lib is a symlink to /usr/lib64. The compiler searches the latter
by default, so /usr/lib won't end up in the search path. References to
/usr/lib, say from a previously installed .la file, may get you
-L/usr/lib additions. Ewww!
More to come hopefully soon.
Cheers,
Ralf