> 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)
+# 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