> I think that if this is going to result in MFC's of things that
> change the libraries for 4.6, that the update of the libc image
> in 5.x for -compat is going to have to wait for 4.6-RELEASE.
That's a good idea.
> 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.
> > 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.
> Are you saying that it breaks because of -current, or are you
> saying it breaks because of the compiler change, or are you
> saying that the compiler in ports is different than the compiler
> that's now in 5.x?
I guess the latest is true. We have a newer snapshot in ports than
in CURRENT. It will be true if gcc31 in CURRENT can build it and
make a running version.
> 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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message