svn commit: r216977 - in head/libexec/rtld-elf: amd64 i386

[John Baldwin]

On Wednesday, January 05, 2011 3:38:16 pm Alexander Best wrote:
> On Wed Jan  5 11, John Baldwin wrote:
> > On Wednesday, January 05, 2011 2:59:20 pm Doug Barton wrote:
> > > On 01/05/2011 10:59, Alexander Best wrote:
> > > 
> > > > judging from the discussion going on right now it seems those flags will be
> > > > grouped together to form a new variable. so things will probably change shortly
> > > > and fixing the order is probably not necessary.
> > > 
> > > Much better to fix the problem properly now than to rely on future work 
> > > that may or may not happen. I realize that you alluded to this later in 
> > > your message, but I think as a general principle this is worth reinforcing.
> > > 
> > > > some people have proposed hacking into clang which i personally think is a very
> > > > bad idea. why not contact the clang developers? they might like the idea of a
> > > > switch disabling all advanced extensions for every architecture?
> > > 
> > > I agree with this. We have a very awkward situation right now with lots 
> > > of local hacks in our version of gcc that in an ideal world we would not 
> > > replicate with clang; particularly considering the much lower barrier to 
> > > entry when it comes to contributing things back.
> > 
> > My suggestion was that we ask clang to add a '-mno-whatever' and hopefully we
> > could convince gcc to follow suit.  clang developers seem to be fairly
> > receptive, so I was hoping one of our clang liaisons could suggest it. :)
> 
> why gcc? even if they decide to add such a switch it will be gpl3'ed. shouldn't
> gcc with clang at hand be considered legacy software?

I think a more realistic view is that some folks will want to use a gpl3
toolchain (e.g. platforms clang doesn't support (or support well) which
need newer binutils, etc.).  The gpl3 bits don't have to live in the tree,
but I think our build infrastructure should support using them as an
external toolchain.

-- 
John Baldwin