Date: Fri, 15 Mar 2002 13:37:39 +0100 From: "Jan Stocker" <jstocker@tzi.de> To: "Terry Lambert" <tlambert2@mindspring.com> Cc: "Alexander Kabaev" <ak03@gte.com>, "Martin Blapp" <mb@imp.ch>, <imp@village.org>, <edhall@weirdnoise.com>, <kris@obsecurity.org>, <current@FreeBSD.ORG>, <hackers@FreeBSD.ORG>, <obrien@FreeBSD.ORG>, <edhall@screech.weirdnoise.com> Subject: RE: gcc -O broken in CURRENT Message-ID: <000001c1cc1e$318e9e80$fe02010a@twoflower.liebende.de> In-Reply-To: <3C911606.D9F74169@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 2) Bug is in os delivered gcc but not in port gcc. > > a) port has more or less patches / os gcc has been modified > > --> Didn't someone told they are the same? > > b) other options were set at compile time > > --> Why dont change to the same in the port? > > Leads it to a broken world? > > If the only difference is the lost of binary compatibility, > > i would say, ok... do it now and we'll need to compile > > or ports... > > SOme bugs are related to the FreeBSD use of setjmp/longjmp > to do exception unwinding rather than using the DWARF primitives. > > When you change the toolchain, you change the exception unwinding > code when you use the ports version. > > You also introduce incompatabilities with the installed libstdc++ > library, which uses the setjmp/longjmp exception unwinding, which > will be in conflict with any exception throwing/handling code > compiled with the ports compiler that uses the DWARF2 version. > > The tests that show it working with the ports version do not test > anything other than bare-bones operation, without testing code > interoperability eith vendor libraries. > > Does that clear things up for you? A little bit... most of you argumenting about binary incompatibility for -stable. OK... no chance to do it there, its my opinion too. But why not doing it for current and using that most common dwarf unwinding now (for a later ia64 port it should be faster than setjump i think). Okay everything needs a recompile but this -current is current and not a production os. You're right that we need a patch for -stable. But if we take the approach for -current maybe we leave these problems behind us and following the path of the rank and file (using dwarf2) and making profit of their experience versus doing this ourself and creating patches. > -----Original Message----- > From: David O'Brien [mailto:obrien@FreeBSD.ORG] > Sent: Thursday, March 14, 2002 7:16 PM > To: Jan Stocker > Cc: Alexander Kabaev; Martin Blapp; tlambert2@mindspring.com; > imp@village.org; edhall@weirdnoise.com; kris@obsecurity.org; > current@FreeBSD.ORG; hackers@FreeBSD.ORG; edhall@screech.weirdnoise.com > Subject: Re: gcc -O broken in CURRENT > > > On Thu, Mar 14, 2002 at 06:36:05PM +0100, Jan Stocker wrote: > > 2) Bug is in os delivered gcc but not in port gcc. > > a) port has more or less patches / os gcc has been modified > > --> Didn't someone told they are the same? > > Port has less patches. If you look at > /usr/src/contrib/gcc/contrib/freebsd.h and > /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things > have to be modified because we support dual ELF/a.out [still]. This may be changed too for 5.0 shouldnt it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c1cc1e$318e9e80$fe02010a>