[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
lucifer@lightbearer.com              http://users.lightbearer.com/lucifer/

Reply to: