libtool-patches
[Top][All Lists]
Advanced

[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




reply via email to

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