Date: Fri, 07 Jun 2002 04:51:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Martin Blapp <mb@imp.ch> Cc: obrien@freebsd.org, david@catwhisker.org, current@freebsd.org Subject: Re: nl_langinfo is MFCed, but what about compat/libc.so.4? Message-ID: <3D009E2A.E94C1F88@mindspring.com> References: <20020607083712.F11797-100000@levais.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Martin Blapp wrote: > > 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. I meant an "extra" bump from 4.5 -> 4.6 and 4.6 -> 5.0. The bump for 5.0 is assumed, since people are doing evil things to system interfaces. > > > 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. 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). > > 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. 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". I needed RTTI on a 3.x system for "typeof" for exception identification of an exception class derived from a base exception class, in order to implement Java 1.1 APIs in C++. Basically, going from GCC 2.93 to 2.95 ended up getting the wrong header files because the .mk file overrode the ports installed compiler header files (and library) when the DESTDIR was set. So if you are having this problem (ports pretty uniformly sets it), it could just be that the system compiler and the ports version header files don't interoperate. You can ask Julian, Archie, or Mark Peek about this; we had to build a new builkd environment to include the GCC 2.95 port, and I had to hack the heck out of the makefiles to put the port header files ahead of the system ones, when using the ports compiler. You could probably do this (mostly -- only for one port) by "which"'ing the $(CC), and then overriding the path by jamming -I and -L into the LDFLAGS and CXXFLAGS conditionally: my hack did it unconditionally). The real issues is narrowing down "broke" a bit, I think, to see if this could be the problem. 8-). 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. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D009E2A.E94C1F88>