Re: FreeBSD patch for dpkg?
On Sat, Apr 26, 2003 at 10:36:03AM -0600, Joel Baker wrote:
>
> I would beg to differ, based on experience with the NetBSD libc. The
> things which are required are:
>
> 1) Someone who can and will *maintain* the libc package. Said person
> should also probably be versed enough in build systems to troubleshoot
> really large and esoteric ones (such as GCC and XFree86), though the
> latter is not an absolute requirement.
This discussion started with someone saying there's an upstream
developer of libc willing to maintain it for FreeBSD.
> 2) A libc that is easily distinguished, has a well known feature set, and
> which is likely to be found as a special case (if one is necessary) in the
> upstream code, already.
at this point we're discarding decently portable software that uses
smart detection systems like autoconf, and entering the collection of
software that thinks `uname -s`-`uname -r` tells everything.
when porting this software to GNU, all you have to do is adding a special
case for [ `uname -s` = "GNU" ], by copy-pasting from the GNU/Linux case
which is very similar (same libc) and doing minor changes. this is the
same we'll have to do when porting to a Glibc-based GNU/FreeBSD.
now for the BSDish-libc-based GNU/*BSD. you will find there's an special
case for it already, yes. but is that what you want? the special case
will assume you're on a native *BSD system, and that won't be entirely
true. what about userland tools, and shell? and if due to Debian's
requirements you start appliing patches to the libc package that make the
required code slightly different? then you'll have to fix that broken
software package to use autoconf.
> This is, I think, the crucial reason why the NetBSD/i386 port has had
> far fewer problems than the Hurd/i386 port.
the GNU/NetBSD port hasn't started yet..
> Hurd uses glibc with subtle
note it's the other way around: Glibc uses the Hurd. if you mean the
whole system uses Glibc, that system is GNU (or GNU/Hurd).
> differences (meaning that just detecting glibc isn't enough), most folks
> aren't aware of how to make use of it's particular feature set (where it
> differs from Linux), and it isn't highly visible to most of the world
> (meaning that if special casing is needed, upstream software is less likely
> to have it).
that's right. but note on almost all our porting situations [1] we
don't need to rely on the canonical `uname -s` check. for example,
for PATH_MAX we just check if that macro is defined.
as you can see in [1], using the __GNU__ macro is highly discouraged.
[1] http://hurd.gnufans.org/bin/view/Distrib/PortingIssues
> NetBSD, on the contrary, is easily detected (programmatically), it's
> feature set is reasonably well known and widely documented, and special
> cases regularly occur in upstream code.
on the *BSD hand, during my porting experience i've found code out
there is full of unportable detections like:
#if defined(__FreeBSD__)
foo
#else
bar
#endif
of course the good solution is to use a system like autoconf. on most
situations "foo" will be what you want, but what if it isn't? then
you'd go crazy trying to define something weird like __GNU_FreeBSD__
or __Debian_FreeBSD__ (depending on what the difference corresponds to),
or would adapt the whole package to use autoconf.
> In fact, *not* using the native libc would mean that we'd have to check
> every one of those special cases to see if it was compatible with glibc
> (ie, is it a NetBSD-only syscall, is it a libc workaround, etc).
No. the question now is what the uname output is. if uname queries
return the same as a native system, you're expected to provide an
identical native libc+kernel (which you can't provide).
if you make uname return something else, eg: GNU/FreeBSD, then a new
special case is added and you can put whatever you like in it. this
typicaly means that code like:
#if defined(__GLIBC__)
foo (this code is suposed to work on any Glibc-based system)
#elif defined (__FreeBSD__)
bar (this code is suposed to work on the real FreeBSD)
#endif
Glibc-based GNU/*BSD will go into the __GLIBC__ special case. that case
_must_ work, if it doesn't it is either a Glibc bug or a bug in code "foo",
and you should just fix that bug. there's no API mismatch.
BSDlibc-based GNU/*BSD will go into the __*BSD__ special case. that
case expects a BSDish libc, so it will most likely work. however, you're
using a modified version of the native libc, on a system with different
userland and a Debian policy that forces modification of a bunch of things.
If that case doesn't match a Debian GNU/BSD/BSD system, that's a though
trouble.
> Also, at least in the NetBSD case, one of the primary reasons to bother
> (now that Linux is capable of handling so many processors) is that the
> kernel+libc can be made much smaller, overall, and at certain specific
> tasks it beats the living snot out of Linux (conversely, Linux has areas
> where NetBSD falls flat on it's face, in comparison :) Much of the benefit
> would be lost, if glibc were layered over the top of it, making the port
> more a matter of curiosity rather than usefulness.
the NetBSD kernel is also much more portable than the kernel Linux. in fact,
that's the only advantage on the NetBSD kernel i see over the FreeBSD one.
--
Robert Millan
make: *** No rule to make target `war'. Stop.
Another world is possible - Just say no to genocide
Reply to: