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
Reply to: