This is the mail archive of the gcc-patches@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] |
On Tuesday 10 April 2012 01:17:36 Adam Conrad wrote: > On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote: > > On Monday 09 April 2012 19:31:40 Adam Conrad wrote: > > > I realize that most people can't see past their own use case to > > > understand why a unique location for linkers is helpful, useful, and > > > important for some other people's use cases, but you either didn't > > > read or chose to ignore why using multilib paths just plain doesn't > > > scale past a single base architecture, and why that's a problem for > > > people who aren't you. > > > > and as already stated, the proposed paths here, free of multiarch > > subpaths, satisfy the requirements that you've put forth > > Like I said, then, you didn't actually read or understand why proposing > multilib paths doesn't work. You realize conceptually, I hope, that > there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once > you cross the base CPU architecture boundary, right? i don't see this as a problem > Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for > us right now, due to sheer luck, and you're running with that as saying > that we clearly have no problem here worth solving. my point was: it works today and has no clashes. that satisfies the "omg we have to ship something $now" and satisfies the requirement that only the Debian people are putting forth (and has already been violated by many targets): the ldso must be unique across all arches/multilibs. > When the next architecture clashes with linkers on another (hint: it almost > certainly will), do we get to argue about this all over again in six months, > instead of codifying a new and saner practice now? i don't buy that it'll happen that soon (since ldso's don't get generated quickly), but that is certainly plenty of time for the Debian project to attempt to convince everyone else that multiarch isn't a waste of time. and does so without holding up moving forward with a unified arm hardfloat abi. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |