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

Re: Soooooooo...

On Fri, Jul 20, 2001 at 11:28:38PM +0100, Matthew Garrett wrote:
> On Thu, Jul 19, 2001 at 07:48:33PM -0400, utsl@quic.net wrote:
> > ii  binutils  The GNU assembler, linker and binary utiliti
> > ii  cpp            2.95.3-7       The GNU C preprocessor.
> > ii  cpp-2.95       2.95.4-0.01042 The GNU C preprocessor.
> > ii  gcc            2.95.3-7       The GNU C compiler.
> > ii  gcc-2.95       2.95.4-0.01042 The GNU C compiler.
> >
> > * gcc: was a complete PITA until I figured out that I didn't have the archtable
> >   setup right in dpkg, and configure was doing bogus things with the arch. I
> >   also disabled everything but gcc itself. (No gcj, g77, gpc, etc.) I think I
> >   had to hack the Makefile for some hurd/linux logic that didn't handle
> >   freebsd. There were a couple packages like that.
> Is this using the stock Debian package for gcc? What have you defined the
> architecture as?

Yes, it was stock gcc from Debian. I had to do some damage to the debian/rules
stuff, though. In the archtable in dpkg, there is a column that is supposed to
be the GNU architecture. This must be set correctly for gcc to be able to build
this package. For my stuff, I set the dpkg architecture to i386-freebsd, and 
the GNU one to i386-freebsdelf. There is also dpkg-architecture under the
scripts directory. It has to be changed separately.

> > I keep running into problems due to not having glibc, so I'm taking a look at
> > porting it next, rather than trying to port all of Debian off of it. Hopefully
> > that'll take care of some of the really icky problems. (i.e. sysvinit,
> > debianutils, etc.) It looks like I need to port ld.so, too, and probably have
> > to hack the FreeBSD kernel to use it, because of the dpkg-shlibdep problem.
> > (That's actually easy. It's a one-line patch to switch the loader path,
> > which'll have to happen anyway to become FHS compliant.)
> That would be pretty cool. I'd be interested to see the patches you end up
> with. A complete GNU system on top of a BSD kernel (rather than a mainly
> GNU with a small amount of BSD one) would be something to aim for, I think
> (not having a GNU libc reduces the value of the Debian GNU/BSD a little,
> IMHO :) ) but I'm currently looking at just using the NetBSD one to avoid
> having to rewrite huge chunks of code...

I don't know what this is going to take yet. I'm a bit confused by the sysdeps
directory in glibc. That's where the system dependent stuff is supposed to go,
and it looks like they did some kind of multiple inheritance thing with
Makefiles...   Probably going to take me a while.

Most of the GNU packages are trouble-free. Where I've been having the trouble
is with the Debian-specific ones.

> > Anyway, I'm working on FreeBSD, making decent progress, and having a lot of
> > fun. If this helps people working on NetBSD, that's cool too.
> Sure. I'm more interested in NetBSD due to the increased portability (I'm
> likely to get hold of an Alpha in the near future, but it's Turbo Channel
> and so won't run Linux. Having Debian on it anyway would be nice :) ), but
> I think the issues involved are going to be pretty much identical in
> both. If we need to contribute any patches to the package maintainers, I'd
> expect them to be beneficial to both kernels.

Some of them. There are a couple (perl is one) that are setup to only support
linux or hurd in the debian/rules. It takes i386-freebsd and turns it into
i386-freebsd-linux, but it knows to turn i386-hurd into i386-gnu. We get to
add support for freebsd and netbsd.

Reply to: