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

[Alexander Best]

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?

cheers.
alex

ps: btw there is a patch in GNATS which bumps base gcc to the very last
revision which didn't include gplv3. i think the patch fixes quite a few
issues: 153298.

also it seems apple is maintaining a gcc branch which has a lot of
improvements, yet it is based on gcc 4.2.1 and thus licensed under gplv2.
i'm not sure if it is avalable somewhere, but having a peek at the changes they
made would in fact be nice. still i don't think tackling base gcc is worth the
hassle, since that time could be spent much better improving clang.

> 
> -- 
> John Baldwin

-- 
a13x