Hi Terry,

> 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).

No no. This has been solved :

 # if (__GNUC__ >= 3)

+#ifdef __FreeBSD__
+#  define _STLP_NATIVE_INCLUDE_PATH ../g++
+#  define _STLP_NATIVE_OLD_STREAMS_INCLUDE_PATH ../g++/backward
 #  define _STLP_NATIVE_INCLUDE_PATH ../g++-v3
 #  define _STLP_NATIVE_OLD_STREAMS_INCLUDE_PATH ../g++-v3/backward

I talk about a different problem. If compiled with the system gcc,
everything builds fine, but coredumps if run.

> 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".

Exactly. Note that the Openoffice Compiles works fine on STABLE, with

- gcc295 from systen
- gcc31 from ports

And in CURRENT it has no other headers to include since this is
a fresh CURRENT and no old headers are lying around.

> 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.

I'll try now a compile with g++3.1 from PORTS on CURRENT. Note that
the STLPORT works with this one. But fails with the system g++.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to