Hi
> 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. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
