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 +#else # define _STLP_NATIVE_INCLUDE_PATH ../g++-v3 # define _STLP_NATIVE_OLD_STREAMS_INCLUDE_PATH ../g++-v3/backward +#endif 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++. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
