On Tue, Apr 09, 2002 at 11:26:56AM -0600, Joel Baker wrote:
> On Tue, Apr 09, 2002 at 11:47:10AM -0400, [EMAIL PROTECTED] wrote:
> >
> > What I ran into with 5.0 was that there was a define that you set to
> > enable compiling with gcc 3.x, and there were some #ifdef's to make it
> > work. However, that define also enabled building gcc 3.x from the
> > FreeBSD source tree, and that failed. Looked like the changes for it
> > aren't quite finished merging in. That was only a week or two ago, so
> > I'd wait a little while yet.
>
> Fair enough. Waiting is fine, but knowing that it's a target is quite
> helpful.
My plan is to continue with 4-STABLE for a while, and try building CVS
snapshots of 5 every so often. Once I get one that builds ok, I'll have to
recompile with the new libc. I made a DBS-like package, so it's not too
hard to change over to -CURRENT.
I'm not in a real rush with it now, because -CURRENT is getting changed
rapidly, and I'm trying to concentrate on making a working Debian system.
What I'd like to do is get my system working well with -STABLE, and get
the base changes merged into Debian. Then playing around with -CURRENT
would make more sense to me.
Otherwise, I'm combining an unstable userland with an unstable libc and
kernel. That's just a bit too hard to debug.
> > These packages are pretty stable. I could upload source and binaries for
> > it, if you've got your machine taking uploads. :-)
> >
> > The main trouble I've got with uploading is going through all the
> > packages I've built, and sorting out which ones needed patching, if it's
> > still necessary, and cleaning up patches where I can. I'm getting near the
> > point where I should just run an autobuilder.
>
> Autobuilders are good. I almost had one up for NetBSD, until I ran into
> problems I couldn't reconcile with system headers (fixed in -current, but
> I can't get that to work on my box, so...)
I've had a few headaches. Here are the major compatibility issues I've
found:
1. getopt_long not in libc. Sometimes alloca, too. Some
Linux/Debian specific programs are not checking for
libiberty functions in configure.
2. unicode/iconv support not in libc. It seems to be missing
multibyte character support.
3. utmp is missing a lot of fields. I solved this by writing
a utmpx implementation.
4. shadow passwords. I'm writing a library that will hopefully
solve this.
> > Hmm, no. I didn't spend much time on it. It was some libc function
> > missing, I think. That's usually the problem. The only reason I tried to
> > build it was because ash depends on it, but ash built fine with
> > FreeBSD's make. I had to have ash for makedev, because it won't work
> > with bash. So ash becomes a base package on FreeBSD, at least for 4.x. :(
> >
> > At this point, I have a package I build from the FreeBSD source tree,
> > that contains all the programs I need to build that source. The circular
> > dependacy is a bit annoying, but that package solves a lot of headaches.
> > (Would you believe it requires the FreeBSD version of find in the
> > Makefiles?)
>
> Differing base packages, while annoying, can be dealt with (albeit with
> some effort, and it might be easier to try to convince FreeBSD to make it
> /bin/sh friendly, I don't know; Debian stuff is *supposed* to not use any
> bashisms, for example, in 'core' areas).
makedev is apparently incompatible with bash. ash works, and so does /bin/sh
from FreeBSD. I just used ash. In 5.0 that goes away, because of devfs,
so I'm not too worried about it.
> The problem is that, at least for me, I'm not trying to build - and don't
> really want present - the majority of the BSD userspace. It won't cooperate
> nicely with the Debian userspace, and it will utterly break a lot of things
> on the underside (the inverse of the 'needs FreeBSD find' - LOTS of things
> assume that they have the Debian-standard 'ls', 'find', etc - though at
> least for find, they need to be declaring a dependancy on the findutils
> package).
>
> Having a make-kpkg equivalent with tools to build a kernel (and, for us,
> libc and similar stuff) is not out of whack, but I'd say those need to be
> kept fairly separate. The BSD make stuff, on the other hand, is used in a
> LOT of stuff outside the kernel.
>
> Of course, that doesn't mean anything but the kernel makes use of the non-
> compatible extensions. Hrrrrf.
My solution was to make a directory /usr/bsd, and I put programs into
/usr/bsd/bin. It looks like this:
skaro:/# ls /usr/bsd/bin
byacc gcov kas kgdb kranlib make objformat xargs
colldef gensetdefs kc++filt kld kreadelf mk_cmds patch yacc
compile_et install kcc knm ksize mkdep sh yyfix
csh kaddr2line kcpp kobjcopy kstrings mknod tcsh
find kar kgasp kobjdump kstrip mktemp tsort
Everything in there was basically required by the FreeBSD Makefiles. When I
build FreeBSD, I put /usr/bsd/bin in the front of PATH, and it works
fine. (I also set CC=kcc, when building the kernel, because I haven't
been able to get it working with the Debian gcc and binutils yet. If
that gets fixed, a lot of that stuff can go away.)
Everything under that directory tree lives in a binary package, called
freebsd-buildutils. That package is built from the FreeBSD sources, and
is a build dependacy for those sources. That's not pleasant, but it
works well. If you want to rebuild the FreeBSD parts of the system, you
install that package.
---Nathan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
