Re: Status of various major things
On Sun, Feb 10, 2002 at 01:29:58PM -0500, utsl@quic.net 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 0xffffffff; 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
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Reply to: