Martin Blapp wrote:
> > I also think that it may mean another major version number change,
> > since there's aren't real minor version numbers any more. 8-(.
> That surly not necessary. We only have major version number change
> if we change from Releng Majors 3->4, 4->5. This is just compat
> stuff, and CURRENT is not yet production.
I meant an "extra" bump from 4.5 -> 4.6 and 4.6 -> 5.0. The bump
for 5.0 is assumed, since people are doing evil things to system
> > > so it doesn't coredump anymore doing the tests. Which means
> > > fixing gcc31 in CURRENT, since the package was build on STABLE
> > > with gcc31 from ports.
> > That last sentence is hard to parse unambiguously.
> stlport breacks within openoffice in CURRENT, or seperatly build
> as a port. I'll have to test if it breaks also with the newest
> snapshot from ports.
I saw a posting of some of the breakage. There was a type that
wasn't defined in scope in a prototype, and then there were a
couple that were missing (e.g. "unexpected ;") because of some
bogus includes. I didn't really see anything that I could blame
on GCC31 itself (I admit it has problems, just not those problems).
> > As a note, I would ask if "DESTDIR" was being set or not? It
> > may be that the reason it's working is that you are getting the
> > old compiler headers instead of the new ones, when you compile
> > it with the new compiler on -stable (I've noted this problem
> > before; the first time was in 1998).
> That's not possible. I'd get to many errors then. I've gcc31 specific
> includes and they work fine.
Not really. The headers that get affected by this are RTTI, and
a couple of others. They would let you compile, and then core dump.
One of the complaints (not sure if it was yours... Trish posted that
the GDB worked locally [albiet an older build]) was "compiled OK,
but core dumped".
I needed RTTI on a 3.x system for "typeof" for exception identification
of an exception class derived from a base exception class, in order to
implement Java 1.1 APIs in C++. Basically, going from GCC 2.93 to 2.95
ended up getting the wrong header files because the .mk file overrode
the ports installed compiler header files (and library) when the DESTDIR
So if you are having this problem (ports pretty uniformly sets it), it
could just be that the system compiler and the ports version header
files don't interoperate.
You can ask Julian, Archie, or Mark Peek about this; we had to build a
new builkd environment to include the GCC 2.95 port, and I had to hack
the heck out of the makefiles to put the port header files ahead of the
system ones, when using the ports compiler.
You could probably do this (mostly -- only for one port) by "which"'ing
the $(CC), and then overriding the path by jamming -I and -L into the
LDFLAGS and CXXFLAGS conditionally: my hack did it unconditionally).
The real issues is narrowing down "broke" a bit, I think, to see if
this could be the problem. 8-).
Gotta tell you though: using GCC31 from ports on -stable *should fail*
when building other ports, because of this, so if it doesn't, it may
be that the *new* header files are broke, relative to e.g. libgcc2.a.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message