re: Status of various major things
BTW, binutils for netbsd-i386 *does* appear to work sanely, and is now in the upstream. At least, it both compiled and run-time linked all the C++ code I could easily put my hands on to test (I used groff, which broke in upgrading to GCC 2.95.4 local compile due to libstdc++ stuff; it's visibly linked to the library, as well, so it SHOULD break in one way or another if anything is seriously wrong... also used a local software project that's very heavily C++ oriented) i got the i386-netbsdelf patches into binutils a while back, yeah. i think they appeared on some later 2.11 branch. binutils 2.12 has (will have) support for pretty much all netbsd ELF platforms.. one thing to watch out for with libstdc++ vs netbsd vs gcc is that our (netbsd) libstdc++ major version number is different to the one that it's distributed with GCC as.. this isn't easy to fix so one must be sure to be using the right version.
Re: Status of various major things
On Mon, Feb 11, 2002 at 11:51:22AM +1100, matthew green wrote: > >I'd believe it. Another reason to use 3.0 as the default, if I can make it >work. Sadly, NetBSD still uses egcs 2.91 as it's default compiler, so I > have >no idea if we might need 2.95 as a kernel compiler. Hopefully we can get >the kernel patched to be clean for 3.0, if it's not. I guess we'll see. > > "it should work." while the in-tree compiler for 1.5 is egcs 1.1.2+patches, > -current has had 2.95 for a while now. also myself and others try to build > kernels & the whole tree with gcc-current at times... we don't tend to have > the same "upgrade gcc, fix kernel" lossage, at least not as badly :-) *dry chuckle* Gee. Someone might think you were referring to something. *Eyes the big message on binutils about breaking 'older, and newer kernels'.* BTW, binutils for netbsd-i386 *does* appear to work sanely, and is now in the upstream. At least, it both compiled and run-time linked all the C++ code I could easily put my hands on to test (I used groff, which broke in upgrading to GCC 2.95.4 local compile due to libstdc++ stuff; it's visibly linked to the library, as well, so it SHOULD break in one way or another if anything is seriously wrong... also used a local software project that's very heavily C++ oriented) -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
re: Status of various major things
I'd believe it. Another reason to use 3.0 as the default, if I can make it work. Sadly, NetBSD still uses egcs 2.91 as it's default compiler, so I have no idea if we might need 2.95 as a kernel compiler. Hopefully we can get the kernel patched to be clean for 3.0, if it's not. I guess we'll see. "it should work." while the in-tree compiler for 1.5 is egcs 1.1.2+patches, -current has had 2.95 for a while now. also myself and others try to build kernels & the whole tree with gcc-current at times... we don't tend to have the same "upgrade gcc, fix kernel" lossage, at least not as badly :-)
Re: Status of various major things
On Sun, Feb 10, 2002 at 11:05:51PM +, David Brownlee wrote: > On Sun, 10 Feb 2002, Joel Baker wrote: > > > I'd believe it. Another reason to use 3.0 as the default, if I can make it > > work. Sadly, NetBSD still uses egcs 2.91 as it's default compiler, so I have > > no idea if we might need 2.95 as a kernel compiler. Hopefully we can get > > the kernel patched to be clean for 3.0, if it's not. I guess we'll see. > > NetBSD-current uses 2.95.3, and I've seen a chunk of commits go > by on the NetBSD lists regarding fixing extra warnings detected > by gcc 3.0, so you may find it easier than you expect :) Fair enough; I'm working from a base of 1.5.2, with the only -current stuff being taken from /usr/pkgsrc. Current status on 3.0: 3.0.4ds1 (the package version) breaks. I'm trying to use CVS HEAD, but the patches are being a royal pain in the rear to massage into applying. We'll see what I can get out of it at the end. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
Re: Status of various major things
On Sun, 10 Feb 2002, Joel Baker wrote: > I'd believe it. Another reason to use 3.0 as the default, if I can make it > work. Sadly, NetBSD still uses egcs 2.91 as it's default compiler, so I have > no idea if we might need 2.95 as a kernel compiler. Hopefully we can get > the kernel patched to be clean for 3.0, if it's not. I guess we'll see. NetBSD-current uses 2.95.3, and I've seen a chunk of commits go by on the NetBSD lists regarding fixing extra warnings detected by gcc 3.0, so you may find it easier than you expect :) -- David/absolute [EMAIL PROTECTED]
Re: Status of various major things
On Sun, Feb 10, 2002 at 01:29:58PM -0500, [EMAIL PROTECTED] wrote: > On Sun, Feb 10, 2002 at 11:14:18AM -0700, Joel Baker wrote: > > XFree86: Builds cleanly, seems to run. Talking to the maintainer about some > > differences in what it builds between the normal and NetBSD versions, and > > how to resolve those. That is, however, the only obvious remaining issue > > before the packages are public. (Well, technically it still has a build > > dependancy on bsdmainutils, which breaks, but it only uses 1 utility, so I > > have that installed manually). > > > > GCC 2.95: Fails many of it's build tests. Also, in practice, appears to > > rather impressively break any C++ code on the system, whether compiled with > > the old or new GCC version. I have reverted my chroot, and things are much > > happier. I'll look into it, but this is a non-trivial problem. > > I had problems with it, too. Main problem seemed to be with libstdc++. 3.0 > fixed that. I'd believe it. Another reason to use 3.0 as the default, if I can make it work. Sadly, NetBSD still uses egcs 2.91 as it's default compiler, so I have no idea if we might need 2.95 as a kernel compiler. Hopefully we can get the kernel patched to be clean for 3.0, if it's not. I guess we'll see. > > GCC 3.0: Doesn't build with the current release in sid, which *looks* like > > it's a 3.0-branch CVS from last week (3.0.4 or so). Going to try to dig up > > a current development branch so that I can drop it's tarball in place, and > > see if that works better. Also build-depends on a newer binutils, which > > is reported to break things. > > Hmm. I'm running gcc 3.0.3ds3, and it seems to work ok. binutils > 2.11.92.0.12.3 does break badly. It core dumps linking c++ code, so I backed > it out, and am running 2.11.90.0.7. I have attached the build log from 3.0 at the end. > > GCC defaults: Currently compiled to default to 2.95. However, I think that > > 3.0 is a much better default for new ports, and would prefer to use this > > instead, once we have a working set of 3.0 packages. Folks should give > > opinions on this one... > > > > Misc: The regex routines in libc appear to be the home of, or trigger of, > > stack corruption. This is what is causing the segfaults in ed, and I > > suspect it is also causing the 'sed' build failures. Compiling and dumping > > a new libc into the chroot did not produce any difference, however. It may > > be compiler issues (thus the efforts on getting a sane set of GCC packages > > which has failed so far). > > I suspect that ed's doing something that compiles, but doesn't actually work > with that implementation of regex. Have you tried linking against a different > regex library? Linking against libed.a, which provides a regex library, works fine (that's why I've been able to build ed-dependant packages). The call to regexec comes back with the pointer passed into it being set to 0x; this clearly indicates stack corruption, because nothing else could actually *cause* that. I don't know what's triggering it, but the end result *shouldn't* be possible in the first place, if things were compiling and linking right. > > Native packaging: I'm likely to play with trying to package at least some > > of the /usr/src/lib stuff later today (such as libc, libarch, etc). On the > > topic of libarch: the source should be called libarch. Should the binaries > > be called 'libarch' as well, or 'libi386', 'libsparc', etc? Personally, I > > vote for 'libarch', because otherwise the dependancies will end up being a > > huge mess... and since switching arches includes replacing 90% of all the > > *other* packages, as well, this shouldn't be a problem. Thoughts? > > If you'd like, you could have the debian directory from my FreeBSD source > package. It'd be a place to start. Indeed. That would be quite useful. :) -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
Re: Status of various major things
On Sun, Feb 10, 2002 at 11:14:18AM -0700, Joel Baker wrote: > XFree86: Builds cleanly, seems to run. Talking to the maintainer about some > differences in what it builds between the normal and NetBSD versions, and > how to resolve those. That is, however, the only obvious remaining issue > before the packages are public. (Well, technically it still has a build > dependancy on bsdmainutils, which breaks, but it only uses 1 utility, so I > have that installed manually). > > GCC 2.95: Fails many of it's build tests. Also, in practice, appears to > rather impressively break any C++ code on the system, whether compiled with > the old or new GCC version. I have reverted my chroot, and things are much > happier. I'll look into it, but this is a non-trivial problem. I had problems with it, too. Main problem seemed to be with libstdc++. 3.0 fixed that. > GCC 3.0: Doesn't build with the current release in sid, which *looks* like > it's a 3.0-branch CVS from last week (3.0.4 or so). Going to try to dig up > a current development branch so that I can drop it's tarball in place, and > see if that works better. Also build-depends on a newer binutils, which > is reported to break things. Hmm. I'm running gcc 3.0.3ds3, and it seems to work ok. binutils 2.11.92.0.12.3 does break badly. It core dumps linking c++ code, so I backed it out, and am running 2.11.90.0.7. > GCC defaults: Currently compiled to default to 2.95. However, I think that > 3.0 is a much better default for new ports, and would prefer to use this > instead, once we have a working set of 3.0 packages. Folks should give > opinions on this one... > > Misc: The regex routines in libc appear to be the home of, or trigger of, > stack corruption. This is what is causing the segfaults in ed, and I > suspect it is also causing the 'sed' build failures. Compiling and dumping > a new libc into the chroot did not produce any difference, however. It may > be compiler issues (thus the efforts on getting a sane set of GCC packages > which has failed so far). I suspect that ed's doing something that compiles, but doesn't actually work with that implementation of regex. Have you tried linking against a different regex library? > Native packaging: I'm likely to play with trying to package at least some > of the /usr/src/lib stuff later today (such as libc, libarch, etc). On the > topic of libarch: the source should be called libarch. Should the binaries > be called 'libarch' as well, or 'libi386', 'libsparc', etc? Personally, I > vote for 'libarch', because otherwise the dependancies will end up being a > huge mess... and since switching arches includes replacing 90% of all the > *other* packages, as well, this shouldn't be a problem. Thoughts? If you'd like, you could have the debian directory from my FreeBSD source package. It'd be a place to start. ---Nathan
Status of various major things
XFree86: Builds cleanly, seems to run. Talking to the maintainer about some differences in what it builds between the normal and NetBSD versions, and how to resolve those. That is, however, the only obvious remaining issue before the packages are public. (Well, technically it still has a build dependancy on bsdmainutils, which breaks, but it only uses 1 utility, so I have that installed manually). GCC 2.95: Fails many of it's build tests. Also, in practice, appears to rather impressively break any C++ code on the system, whether compiled with the old or new GCC version. I have reverted my chroot, and things are much happier. I'll look into it, but this is a non-trivial problem. GCC 3.0: Doesn't build with the current release in sid, which *looks* like it's a 3.0-branch CVS from last week (3.0.4 or so). Going to try to dig up a current development branch so that I can drop it's tarball in place, and see if that works better. Also build-depends on a newer binutils, which is reported to break things. GCC defaults: Currently compiled to default to 2.95. However, I think that 3.0 is a much better default for new ports, and would prefer to use this instead, once we have a working set of 3.0 packages. Folks should give opinions on this one... Misc: The regex routines in libc appear to be the home of, or trigger of, stack corruption. This is what is causing the segfaults in ed, and I suspect it is also causing the 'sed' build failures. Compiling and dumping a new libc into the chroot did not produce any difference, however. It may be compiler issues (thus the efforts on getting a sane set of GCC packages which has failed so far). Native packaging: I'm likely to play with trying to package at least some of the /usr/src/lib stuff later today (such as libc, libarch, etc). On the topic of libarch: the source should be called libarch. Should the binaries be called 'libarch' as well, or 'libi386', 'libsparc', etc? Personally, I vote for 'libarch', because otherwise the dependancies will end up being a huge mess... and since switching arches includes replacing 90% of all the *other* packages, as well, this shouldn't be a problem. Thoughts? -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
