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.
Re: thoughts on architectures
On Mon, 11 Feb 2002, Marcus Brinkmann wrote: > > 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). > Maybe there should be several "layers" of Packages files. The top layer being a basic packages list used by a simple CD vendor like myself, a second which contains more problematical packages that will run more or less eg, specifically optimised packages for i686. A third layer could contain, for example, those that need some form of emulation. These could be called Packages, PackagesA, PackagesB and suitable modifications made to dpkg. I would imagine that there would have to be manual intervention by the guru when installing from PackagesB. I realise that there would have to be some way of creating these Packages files and that the basic problem has been moved to somewhere else, but as a consumer, this is what I would like to see happen. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux & GNU/Hurd CDs. See http://www.copyleft.co.nz
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
> 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.
re: thoughts on architectures
Bear in mind that quite a few systems already support multiple kinds of binaries, and there are more on the way. Sparc, ia64 and x86-64 (not sure if x86-64 is a Debian arch yet) all can do both 64 and 32 bit binaries. I think s390 might too, but I'm not sure. The packaging system needs to know how to deal with the situation. The BSDs can run Linux binaries, and also run on some of the same 64/32 bit platforms. on my netbsd/sparc64 box running a 64 bit kernel, i can run these binaries: - native (elf64_sparc) - elf32 sparc (netbsd) - a.out sparc (netbsd) - a.out sunos - elf32 svr4 - elf64 svr4 i don't think we ever did a.out 64bit so that doesn't count... the libraries for these are located in several places: - /usr/lib - /emul/netbsd32/usr/lib - /emul/aout/usr/lib - /emul/sunos/usr/lib - /emul/svr4 - /emul/svr4 (the latter two because solaris defines different paths 64bit code, something that netbsd hasn't gotten around to working out how to do properly yet.) Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark it's binaries. That's how it knows when to start emulating Linux syscalls. So it's effectively using an altered ELF format on i386, as well as a different libc. But it's capable of supporting libc6 in Linux emulation mode. Of course, dpkg doesn't know that... that would be "FreeBSD abuses the ELF OSABI" but nevermind :-) NetBSD uses an ELF note section, rather than mark their binaries as "not ELF" (which is what setting OSABI means -- bad name yes.)
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: 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 Sun, Feb 10, 2002 at 10:34:36PM +0100, Marcus Brinkmann wrote: > Hi, > > (I am not subscribed. You might CC me on interesting threads/sub-threads) > > From: [EMAIL PROTECTED] > "The major oversight is that he completely fails to mention libc. And for us, > that remains a big issue. Right now, and for immediately forseeable future, > I'm not going to be using glibc." > > There is nothing special about libc. It Depends on some kernel, cpu and > possibly other stuff, and provides a library api (soname). > > Sonames should be handled completely automatic by the build system (in > Debian they aren't) with optional overrides in case of incompatible libs > with the same soname (don't do that, though). 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. > Programs also might depend on an object format, or you might assume the > object format is common for all programs depending on the same interfaces. > EG, if you assume a common object format, all packages depending on > libc.so.6 are ELF by definition. Otherwise the object format has to be > coded into the dependencies. Bear in mind that quite a few systems already support multiple kinds of binaries, and there are more on the way. Sparc, ia64 and x86-64 (not sure if x86-64 is a Debian arch yet) all can do both 64 and 32 bit binaries. I think s390 might too, but I'm not sure. The packaging system needs to know how to deal with the situation. The BSDs can run Linux binaries, and also run on some of the same 64/32 bit platforms. > A program that depends only on i386, libc.so.6 and optionally elf, will run > on all systems that have libc.so.6, understand the elf object format and can > emulate or provide i386 instructions. That's what I was looking for. Essentially, you're setting up dependacies based on CPU and API's needed, rather than using just architecture. That's a good idea, and I'm in favour of it. However, it won't really help me all that much, because just about everything is going to depend on libc6, and it doesn't work on FreeBSD. Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark it's binaries. That's how it knows when to start emulating Linux syscalls. So it's effectively using an altered ELF format on i386, as well as a different libc. But it's capable of supporting libc6 in Linux emulation mode. Of course, dpkg doesn't know that... > Philipp: > "However, we CD image builders are simple folk with an include/exclude > mentality and not much time for subtle distinctions." > > My proposal shall not worry you. A distribution will look similar to the > distributions that exist in Debian right now. There is no need to change > how a distribution will look to a user. For you and others, it will simply > be a list of packages to pick from, out of a pool. 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.
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: 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 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: thoughts on architectures
Hi, (I am not subscribed. You might CC me on interesting threads/sub-threads) From: [EMAIL PROTECTED] "The major oversight is that he completely fails to mention libc. And for us, that remains a big issue. Right now, and for immediately forseeable future, I'm not going to be using glibc." There is nothing special about libc. It Depends on some kernel, cpu and possibly other stuff, and provides a library api (soname). Sonames should be handled completely automatic by the build system (in Debian they aren't) with optional overrides in case of incompatible libs with the same soname (don't do that, though). Programs also might depend on an object format, or you might assume the object format is common for all programs depending on the same interfaces. EG, if you assume a common object format, all packages depending on libc.so.6 are ELF by definition. Otherwise the object format has to be coded into the dependencies. A program that depends only on i386, libc.so.6 and optionally elf, will run on all systems that have libc.so.6, understand the elf object format and can emulate or provide i386 instructions. Philipp: "However, we CD image builders are simple folk with an include/exclude mentality and not much time for subtle distinctions." My proposal shall not worry you. A distribution will look similar to the distributions that exist in Debian right now. There is no need to change how a distribution will look to a user. For you and others, it will simply be a list of packages to pick from, out of a pool. 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
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: 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/
Re: patch to add FreeBSD support
On Sun, Feb 10, 2002 at 11:48:56AM -0600, Adam Heath wrote: > 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. Yes, it only affects configure. There's no equivilent patch for dpkg --print-architecture. That still has to have an exact match in the archtable. Changing that would add a dependacy on a regex library. I've configured gcc as i386-unknown-freebsd4, because gcc's configure knows that versions < 4 are a.out. That allows --print-architecture to find the arch by i386-freebsd4 in the archtable. I may have to add freebsd5 for 5.0 later, but that's much easier than dealing with every minor release, or patching every configure and config.guess in Debian. At some point, it may be desirable for config.guess to be able to distinguish Debian FreeBSD from regular FreeBSD. That could solve the problem here nicely. ---Nathan
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.
Re: patch to add FreeBSD support
On Sun, Feb 10, 2002 at 01:44:52AM +0100, Wichert Akkerman wrote:
> Previously [EMAIL PROTECTED] wrote:
> > --- dpkg/utils/start-stop-daemon.c Fri Feb 1 23:28:13 2002
> > +++ dpkg-1.10-freebsd/utils/start-stop-daemon.c Fri Feb 8 04:36:55 2002
> > @@ -707,7 +709,9 @@
> >
> > /* WTA: this needs to be an autoconf check for /proc/pid existance.
> > */
> > -#if defined(OSLinux) || defined (OSsunos)
> > +
> > +/* WART: FreeBSD also has /proc support */
> > +#if defined(OSLinux) || defined (OSsunos) || defined(OSfreebsd)
>
> Removed the WART comment, that was already covered by the statement
> above that.
That was an inheritance from Wartan Hachaturow's patch, some months ago. It's
probably not important...
> > diff -urN dpkg/configure.in dpkg-1.10-freebsd/configure.in
> > --- dpkg/configure.in Sat Feb 2 17:58:58 2002
> > +++ dpkg-1.10-freebsd/configure.in Fri Feb 8 23:35:45 2002
> > @@ -93,7 +93,7 @@
> >
> > dpkg_archset=''
> > AC_MSG_CHECKING(Debian architecture)
> > -dpkg_archset="`awk '$1 == "'$target_cpu-$target_os'" { print $2 }'
> > $srcdir/archtable`"
> > +dpkg_archset="`perl -ane 'if("'$target_cpu-$target_os'"=~m#^$F[0]$#)
> > {print $F[1]; exit(0)}' archtable`"
> > # Finish off
> > if test "x$dpkg_archset" = "x"; then
> > AC_MSG_RESULT([$target_cpu-$target_os, but not found in archtable])
>
> Please don't use perl there, I want to get rid of all perl in dpkg.
Sorry, it was the first implementation that came to mind. I'll see if I can
remember how to use awk well enough to get it to do that. Is the basic concept
acceptable?
