This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ping: build testing broken for many multilib targets


On Tue, Feb 08, 2005 at 06:00:16PM -0800, Mark Mitchell wrote:
> David Edelsohn wrote:
> >>>>>>Mark Mitchell writes:
> >
> >
> >Mark> I think that the "flat" layout is just wrong.  The right layout is 
> >the Mark> same as the one used in the installed tree (modulo 
> >Mark> MULTILIB_{OS,}DIRNAMES, I guess).  That's the right thing, for lots 
> >of Mark> reasons -- not least because there's no point in being different 
> >from Mark> the installed tree, unless there's a compelling reason.  That 
> >means that Mark> I think that the old layout's "libgcc_s_<multilib>.so" 
> >links are bogus.
> >
> >Mark> I've heard people suggest that these links were a win in that it 
> >made it Mark> possible to avoid putting as many directories in 
> >LD_LIBRARY_PATH at Mark> run-out-of-builddir time, but I think that's 
> >specious; eliminating the Mark> differences between build and installed 
> >trees is more important.
> >
> >	The flat model was a conscious decision when libgcc_s_<multilib>
> >was implemented.  I think that we at least should ask the designer,
> >Richard Henderson, before unilaterally changing it.
> 
> Well, Richard, what say you?
> 
> I think that it's bizarre to segregate all of our other libraries into 
> appropriate multilib directories, including static libgcc, but not the 
> shared libgcc.

The problem I was originally trying to solve is to give different
multilibs different sonames, so that we don't accidentally resolve
to a library with the wrong abi.

It's true that this doesn't work as expected with bi-arch targets,
and that may be reason enough to quit.

Additionally, none of our other libraries take this abi difference
into account, so folks already have to work around that, so it's
probably not worth worrying about at all for the special case of
libgcc.

So I guess you can kill it if you want.



r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]