Re: patch to add FreeBSD support
On Sun, 10 Feb 2002, Wichert Akkerman wrote: Please don't use perl there, I want to get rid of all perl in dpkg. This is during the build of dpkg. That's a completely different area then the running of dpkg.
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/
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/
Package count
Current package counts in the archive: unstable/binary-netbsd-i386: 103 unstable/all: 66 Not too shabby... -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
Re: Build machine
I have this problem to, anyone know why? Seems like Stop is corrupted, but isnt that platform independent code? anyway, got my netbsd-debian system up now so expect some packages soon, but apt would be great so we all could get synced. //Tobias On Fri, 2002-02-08 at 00:26, [EMAIL PROTECTED] wrote: That's interesting. I've been having similar problems with it. I just discoverd that it would accept either the sources lines or my binaries line, but not both at the same time. I'm not sure, but I suspect it's trying to match up source packages with binary packages, and running into inconsistancies. See if this is similar to what you get: (gdb) bt #0 0x280f51dd in pkgTagSection::Scan(char const*, unsigned long) () from /usr/lib/libapt-pkg.so.3.2 #1 0x280f4eb8 in pkgTagFile::Step(pkgTagSection) () from /usr/lib/libapt-pkg.so.3.2 #2 0x28121a87 in debListParser::Step() () from /usr/lib/libapt-pkg.so.3.2 #3 0x28111c84 in pkgCacheGenerator::MergeList(pkgCacheGenerator::ListParser, pkgCache::VerIterator*) () from /usr/lib/libapt-pkg.so.3.2 #4 0x2812af84 in debPackagesIndex::Merge(pkgCacheGenerator, OpProgress) const () from /usr/lib/libapt-pkg.so.3.2 #5 0x28114e51 in pkgCacheGenerator::WriteUniqString(char const*, unsigned) () from /usr/lib/libapt-pkg.so.3.2 #6 0x2811521d in pkgMakeStatusCache(pkgSourceList, OpProgress, MMap**, bool) () from /usr/lib/libapt-pkg.so.3.2 #7 0x2810c625 in pkgCacheFile::Open(OpProgress, bool) () from /usr/lib/libapt-pkg.so.3.2 #8 0x0805957b in DoUpdate(CommandLine) ([EMAIL PROTECTED]) at apt-get.cc:85 #9 0x280e440a in CommandLine::DispatchArg(CommandLine::Dispatch*, bool) () from /usr/lib/libapt-pkg.so.3.2 #10 0x0805f380 in main (argc=2, argv=0xbfbffc48) at apt-get.cc:2174 #11 0x08052130 in _start () On Thu, Feb 07, 2002 at 03:42:02PM -0700, Joel Baker wrote: The build machine is out of order until such time as I can get apt-get to not segfault on things like any source list, including a completely empty one. Even working from a brand new chroot install isn't helping. Of course, the totally unexplained well, sometimes it segfaults, and then sometimes it does that I've had with it for the past 2 weeks just appears to have become it always segfaults. Maybe it will decide it likes me in a few hours. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Tobias Rundström Chief Technical Officer nbsp;Solutions [EMAIL PROTECTED] +46 709 95 29 33 +46 40 29 57 57 (office) +46 40 29 57 30 ( fax)
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: thoughts on architectures
On Sun, Feb 10, 2002 at 09:28:35PM -0500, [EMAIL PROTECTED] wrote: Like libc.so.4 on FreeBSD, soon to be libc.so.5? Not compatible with libc5 on Linux. It's confusing, but I don't know any good way around it. Well, then you have to include the OS-ABI field into the dependency name for all library dependencies. As the information is easily available from the binary with objdump, this can be as automatic as the soname. You have to make such decisions based on the universe you live in. If you build a distribution that only ever has binaries from a single ABI tag, you don't need to include it. But if you have different ABI tags you want to support, you mangle it into the dependency name. Bear in mind that quite a few systems already support multiple kinds of binaries, My text was written with that in mind. Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark it's binaries. The GNU/Hurd does it as well. Of course, dpkg doesn't know that... dpkg doesn't know a lot of things ;) That should be correct. A distribution already is just a Package file with references to files in the pool. No real change there. The difference would seem to be in the generation of the Packages file. Yes, exactly. And you need some differences in the algorithm that decides when to compile a package from source for a given architecture (the pool might contain a compatible but inferior binary package). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: thoughts on architectures
On Mon, Feb 11, 2002 at 02:35:50PM +1100, matthew green wrote: Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark it's binaries. The GNU/Hurd does it as well. hmm, last i looked hurd used an ELF note, like NetBSD. Yes, sorry, I thought that was he meant (and he did :). I did not even know about a special OSABI field. ulysses:/tmp/x# objdump -s -j .note.ABI-tag /bin/bash /bin/bash: file format elf32-i386 Contents of section .note.ABI-tag: 8048108 0400 1000 0100 474e5500 GNU. 8048118 0200 1e00 ulysses:/tmp/x# objdump -s -j .note.ABI-tag /gnu/bin/bash /gnu/bin/bash: file format elf32-i386 Contents of section .note.ABI-tag: 8048100 0400 1000 0100 474e5500 GNU. 8048110 0100 Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: thoughts on architectures
On Mon, Feb 11, 2002 at 04:41:07AM +0100, Marcus Brinkmann wrote: On Mon, Feb 11, 2002 at 02:35:50PM +1100, matthew green wrote: Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark it's binaries. The GNU/Hurd does it as well. hmm, last i looked hurd used an ELF note, like NetBSD. Yes, sorry, I thought that was he meant (and he did :). I did not even know about a special OSABI field. ulysses:/tmp/x# objdump -s -j .note.ABI-tag /bin/bash /bin/bash: file format elf32-i386 Contents of section .note.ABI-tag: 8048108 0400 1000 0100 474e5500 GNU. 8048118 0200 1e00 ulysses:/tmp/x# objdump -s -j .note.ABI-tag /gnu/bin/bash /gnu/bin/bash: file format elf32-i386 Contents of section .note.ABI-tag: 8048100 0400 1000 0100 474e5500 GNU. 8048110 0100 There's a field in the ELF header called OS/ABI. Readelf -h finds it, and it looks like this: Normal binaries: OS/ABI:UNIX - System V FreeBSD binaries: OS/ABI:UNIX - FreeBSD I need to look into it a bit more, and figure out exactly what FreeBSD does and doesn't do with this.
