the most merged BSD make i'm aware of is:
http://www.crufty.net/help/sjg/bmake.html
.mrg.
that get ported can Provide: (since something like 90%+ of packages don't
need anything that isn't shared between all four variants I know of in
common use), and stop trying to pretend they're mergeable into a single
utility.
i'd expect macos freebsd to converge on the same tool.
This may be possible under NetBSD as well (especially with a generous
helping of COMPAT option enabling), but given the number of dire warnings
the manuals all bear about building things in the correct order, I'm not
willing to trust that it's flexible enough to start doing
No, we combine the advantages of Debian, GNU, and the kernel of NetBSD.
The superiority of GNU userland repect to NetBSD's is an issue too, and you
seem to be ignoring it.
no, it's more that we (at least perry and i, and most of the netbsd
developers) _don't think GNU userland
A usable Debian GNU/KNetBSD system based on Glibc is now available:
so... can someone explain what the plan is for deb/netbsd wrt libc?
ie, will there be 2 systems one that is compatible with netbsd (ie
that people can upgrade to, run normal netbsd apps, etc) and one that
isn't (ie,
- makext probably means userland, so sys-bsd.c is highly likely to assume
FreeBSD. we have GNU userland, which is what the sources call linux, so
we set makext=linux (it's ugly to call it like this, but i can live with
it ;))
no. sys-bsd.c is the code to talk to a BSD-like ppp
1) __cxa_atexit - This can be worked around (GCC is patched to avoid
using it), but it's fugly and really should be fixed. Conveniently, in
-current, it is (after a PR requesting it). Can be backported, though I'm
not entirely sure I'm comfortable with that, given how it affects
it is a bug if a new kernel with (all) COMPAT options is not able to
run old software. perhaps the only exception to this is ld.elf_so,
but in general that also applies (there *are* exceptions though.)
I don't understand this - does this mean that all
To David Brownlee: I doubt NetBSD 1.0 binary could run against
a NetBSD 1.6 libc. They don't care much about binary compatibility. You
could not even run a statically linked 1.0 app without some COMPAT_
option in the kernel, I think.
when making such assertions it helps to be
They presumably did it because they thought it would be a good idea.
Perhaps they wanted to hide implementation differences between
different OSes. Either way, the low-level functions in FreeBSD work
just fine.
FWIW, i just ran man funopen on my netbsd box and it says:
HISTORY
when making such assertions it helps to be actually correct. while it
is true that *any* old binary may require COMPAT_XX options in the kernel,
netbsd supports binaries back to 386bsd for i386, with shorter periods
of backwards compat for the newer plaforms. i have personally
On Wed, Jan 15, 2003 at 09:34:45AM -0600, Steve Langasek wrote:
On Wed, Jan 15, 2003 at 07:31:42AM -0600, Colin Watson wrote:
On Tue, Jan 14, 2003 at 05:40:45PM -0600, Steve Langasek wrote:
FWIW, I did some research into nl_langinfo() for an upstream recently,
and found
There should be no real problem with this, except that you'll need native
versions of some of the NetBSD tools used during make (the NetBSD make,
for a start). Make doesn't trivially build on Linux, but if someone wants
to take a look at that it'd be a sensible thing to package.
Well, IMHO the first thing to know is about the concepts of the other
port.s.
Indeed. It's probably best we fall in line with the other *BSD port,
especially the NetBSD ports on ia32 and alpha.
i strongly suggest following the ia32 port's lead.
Which parts of NetBSD are
Your webpage says Note that for now, it looks like you can't have two
NetBSD partitions on the same drive on i386.
This is unclear.
I use NetBSD i386 with multiple fdisk partitions on same disk (although I
only boot from one).
until recently, i believe this was not well
Indeed, some investigations with nm and perl show that basically all of the
core (libc12) libraries depend on libc for some set of their functions.
The only odd bits are libutil (which depends on libposix for chown, easy
enough to link) and libc, which has the undefined symbols
OpenBSD appears to be more heavily audited though. Maybe it's just
appearance. You may have seen in the Debian Weekly News that I'm working
on a rough audit project and in such I would like to say that security
must include a heavy code audit.
i think 'appears' is a great word
Need someone with more familiarity with NetBSD's intricacies to assist on
this one. Currently, lintian is throwing a spew of a single error (one per
library, in both libc12 and libc12-dbg), based on the fact that NetBSD,
unlike Linux, does not have every library dependant on libc
Okay. So it's a matter of historical FUBARism - which means I should, at
the very least, have a FIXME to find some way to fix it, and not turn
off the warnings.
NetBSD arguments aside, this information *should* be used on Debian, simply
because it becomes very important when
Suggestions on how to properly figure out which libraries things must
link
against (especially involving libraries which may or may not be present,
such as libi386 and libm387 - especially the latter) would be
appreciated.
well, libi386 is linked into
At present, dpkg won't build because it can't find obstack.h, which
seems to be part of glibc. Is there a patch for dpkg that I need?
isn't obstack part of libiberty?
it appears to be from my netbsd toolchain tree.
NetBSD. Licensing.
Appears to be old (non-revised) BSD license... certainly the INSTALL.txt
file for 1.6 has lines at the beginning of the ungodly long section for
the NetBSD project (in two forms, no less!)
Pardon me while I sink into despair of ever untangling the
as far as i'm aware, there are very conflicting views on mixing
GPL 4-clause software. to me, calling them incompatible such
that you refuse to link apps libraries because of it is way over
stepping the mark, espcially if you are linking GPL apps against
a BSD system -- are you going to
It's the INSTALL.txt file, not a copyright file. I have not (yet) been able
to find a copyright or license file that directly applies to the sources
in CVS, either on the website or in CVS itself. Anyone who knows where the
heck the thing is hiding, do tell. :)
look in
hi folks.
just a FYI.
not sure if you saw or not, but when netbsd switched to dynamic
everything, a new /libexec directory was created to hold ld.elf_so.
it's not in /lib.
btw, what is the status of libc vs. glibc? if glibc is the 'default'
how does someone run a standard netbsd application
Hmmm. The origional plan had said /lib.
yeah, i know. that's why i told you :-) basically, enough people
complained that not using /libexec/ld.elf_so would be to break the
consistency of the system, yadda yadda yadda. i don't care and
prolly would have preferred to not have a new
The only packages where this caused any great trouble were gcc and
binutils, and that was fairly easily rectified.
GDB?
Note that in the case of non-i386 ports, where 'unknown' may actually
be a
valid vendor, config.guess is *only* filling it out if there is a single
vendor value - IE, something that can be put into the archtable as-is,
and
come back out again without conflict. So
Be warned: on at least some architectures (notably IA-64), this sort of
read has been known to cause untrapped machine checks (a.k.a., lockups
or spontaneous reboots). Arguably the kernel should trap this sort of
nonsense, so you may be in the mood to file a bug against kernel
Think you could port BSD libc to Linux without making a mess?
considering that we (netbsd) basically have a source-compat layer
for netbsd software on linux, this actually is a whole lot simplier
and easier than you may otherwise think.
The BSD libc is smaller for about the same
I have a sufficiently working glibc that I can build binutils and gcc
against it and then use them to rebuild a working glibc, but it'll need
some work yet before it's even vaguely production ready. The general
opinion at Debconf seemed to be that going with glibc was preferable to
can't we have both?
There's certainly no problem shipping both - what I was thinking about
more is which do we link everything against?
i know of at least one bug in glibc that wasn't a candidate for being
fixed (last i heard.) it's nfs_readdir() depends on an opaque cookie
I think using /usr/bsd, as I do now, is fairly simple. Given the
complexity of the source package's build system, I'd like to keep it
simple. (Keep in mind, this is only required to build the freebsd
source package. You don't need it for anything else.) I think I really
1) Modify the kernel build so uname -v includes Debian - this is a
pretty trivial change. It does present problems if people build kernels on
their own - one option would be to make sure that the kernel build system
ensures that this is set.
i think this will only cause things to
Looked like a bourne shell to me. Default root shell is /bin/csh on
FreeBSD, but I believe /bin/sh is basically the same as ash.
Interestingly, MAKEDEV fails to work with bash but works fine with ash.
i'm not sure about freebsd, but netbsd has used ash in /bin/sh
for a Long Time.
2) config.guess currently produces i386-unknown-netbsdelf1.5. Under
Linux,
this is i386-pc-linux-gnu. Adding i386-unknown-netbsdelf1.5-gnu (or
possibly even just i386-unknown-netbsd-gnu), determined by the different
uname output, would allow for Debian-specific
1) FreeBSD 5.0 pre-release... does anyone know if it's GCC 3.x clean? If
so, I might futz with trying to do up a chroot based on that, at some point
here... unless someone else desperately wants to do it or something.
2) pmake (aka /usr/src/usr.bin/make) - the source tree for
On Sun, Mar 17, 2002 at 06:55:26PM +0100, Jeroen Dekkers wrote:
This is certainly true. It's a wishlist item, it would be nice if all
free kernels would use multiboot. I've heard that grub will at least
be partly rewritten to make some new features possible, it might also
be
The NetBSD loader is, unsurprisingly, not subject to this restriction.
I'd
be tempted to go with packaging this and using it as our primary boot
mechanism unless anyone objects. The one problem I can think of is that
it
stores the bootcode in /boot, which is a directory
GRUB appears capable of booting the kernel, but can't pass any kernel
options. This appears to include passing the root file system, requiring
it to be typed by hand later on.
The NetBSD loader is, unsurprisingly, not subject to this restriction. I'd
be tempted to go with
How exactly can I work on the BSD kenrel on my iMac running Debian Sid
PPC Linux? I have a 12 gig hard drive.
hmm, do you have another (unix) machine? netbooting netbsd on the mac
is the simplest way to do this, and it doesn't require repartiting
your hard drive... if you don't, you'd
On Sun, Feb 24, 2002 at 08:43:11PM +, Matthew Garrett wrote:
Fakeroot on NetBSD is dying inside libfakeroot. The mess of wrap* has left
me sufficiently confused that I'm not really sure what's going on, and
I've certainly got no idea why it dies. Does anyone who understands
there are lots of versioned system calls. i'm sure this really
affects more than fstat(). the others probably just cause less
drastic (but potentially more dangerous!) lossage.
Yup, it looks like fstat, lstat, stat, chown, chown, fchown, lchown and
possibly a couple of
FYI:
a basic implementation of utmpx has been commited to netbsd-current,
completely indepedant of any work done here... i don't believe it is
100% complete yet.
On a separate note, msyslogd builds happily but uses /dev/log as its
socket by default. The NetBSD logging functions seem to be expecting
/var/run/log - symlinking the two work, and you can pass an option to
msyslog to make it produce /var/run/log instead. What's the preferable way
I thought sockets weren't affected by read-only filesystem. Just out
of curiousity, why should they be if the node is already there? There'd
be no actual writing to the filesystem. Do fifo's not work either?
creating a socked or a named pipe is creating a file on the
file system.
On Tue, Feb 19, 2002 at 08:59:15PM -0700, Joel Baker wrote:
So... pmake claims to be BSD 4.4 make, and in fact appears to be a not-
unreasonable copy of the NetBSD make sources. Is there any particular
reason that the make-bsd and netbsd-mk packages in the chroot can't be
I'd been under the impression that pmake was some sort of parallel make
(though I'm not sure why), so that can probably be assumed to just be me
being stupid. I don't see any reason not to use pmake instead (other than
it being a bit out of date).
it is. parallel
So... pmake claims to be BSD 4.4 make, and in fact appears to be a not-
unreasonable copy of the NetBSD make sources. Is there any particular
reason that the make-bsd and netbsd-mk packages in the chroot can't be
replaced by the Debian-standard pmake package, if it gets updated (it's
On Wed, Feb 20, 2002 at 03:02:26PM +1100, matthew green wrote:
So... pmake claims to be BSD 4.4 make, and in fact appears to be a
not-
unreasonable copy of the NetBSD make sources. Is there any particular
reason that the make-bsd and netbsd-mk packages in the chroot
This leads to the question of keeping pmake in sync with the source version
that it's meant to build. Perhaps I need to do a pmake-version instead,
make it conflict with pmake, and figure out how to do it saner, later...
hmmm look for simon gerraty's autoconfistcated pmake -- it's
As best I can tell, with the native NetBSD sys/socket.h, if a problem in
any way defines (or triggers definition of) _POSIX_SOURCE or _XOPEN_SOURCE,
anything which calls sys/socket.h will break horribly (since it uses values
from types.h - which it also fails to include on it's own -
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
XFree86 is wanting to link against libi386, which appears to be a NetBSD
specific library to handle some special processor manipulation. Can this
be ported to Debian? Should it? Is there a reasonable way to work around
code which wants these? Advice from NetBSD Gurus sought :)
On Sat, 2 Feb 2002 [EMAIL PROTECTED] wrote:
getopt is in libiberty. It's also in glibc, and people have a bad
habit of not checking for that in configure. I'm thinking about
packaging libiberty, and
Also a BSD-licensed getopt (and getopt_long) is available
Also a BSD-licensed getopt (and getopt_long) is available in the
NetBSD
libc.
But behaves differently to GNU getopt_long, as regards its handling of
the arguments '-' and '--'
it does? this sounds like a bug. it should be compatible.
As far as I can tell, the main difference is that - (bare) is considered
illegal in the NetBSD setup. I don't have any easy way to test what the
difference in -- is, though long usage would *imply* that it means end
parsing of all arguments here in the GNU world.
OK, i'll see what
As I said, FreeBSD's resolver really didn't like the Linux version of the
file,
which is in base-files.
OK. i'm fairly sure this won't affect the netbsd port cuz
it won't be used at all as far as i can tell...
However, I'm still building with the NetBSD gcc/binutils/libc, and I
figured that now would be a good time to switch to a Debian native
compiler. =)
To accomplish this, I have binutils configured with
--target=alpha-netbsd --prefix=/some/path
and compiled
i think that most target tuples that `config.guess' generates have the
OS version included. certainly i can't think of anything except linux
that doesn't :-)
As you can see, different output by different config.guess scripts.
Also notable, the config string doesn't tell you I'm
A) Use this file at all?
B) Support the 'compat' entries (the only major difference between the
tarball and the distributed file).
this is the default nsswitch.conf (ie, if none is present):
groupcompat
group_compat nis
hosts
At least on FreeBSD, shared objects can't be ldd'd, which happens to be
exactly what debhelper does. Perhaps these .so's don't include information
for ldd to extract? It's really weird, because it's supposed to be ELF.
fortunately, on NetBSD, this isn't an issue. our ldd(1) is
In the current chroot, /usr/include/db.h and /usr/include/db2/db.h
seem to be from the netbsd db1. /usr/lib/libdb2.* seem to be the
libraries from the debian db2 package. /usr/lib/libdb.* are symlinks
to the db2 libraries. This is helping to cause the apt build to fail.
It is also
On a related note, FreeBSD's Makefiles use make sometimes where they should
use ${MAKE}, so I put the BSD make into /usr/bsd/bin. Then I mangle $PATH
before running make from debian/rules, so that the FreeBSD Makefiles always
get BSD make rather than GNU. Sounds like NetBSD has
Well put, and an important point. MY understanding of RMS, and of the BSD
license would seem to indicate that what's done with the code is no one's
business. If your M$, and you want to absorb BSD code, or some evil
dicator somewhere, it doesn't matter, the code is free to use,
utilities and libraries NEED to be built together with the kernel. It's a
feature in the BSD world. It'd be easer to keep them in sync if they're built
hmm, i wouldn't call it a feature :-) certainly in NetBSD we've done a
lot of work to remove these sorts of issues... and the trend
I would *much* rather have the non-dependant stuff, of which there is a
whole lot, built as separate packages. Wherever the source comes from, I
don't want to have to rebuild a lot of cruft that isn't actually crucially
out of date, just to get a reasonable kernel. If I rebuild my
that's only for i386. i'm still waiting for my sparc/sparc64 patch
to be commited (i should ping them) and i don't know the status of
other netbsd gcc ports in gcc-current, really, at all...
Joy :) Is the 2.95 in the ports tree suitable for all architectures?
i really
NetBSD chroot environment, and I didn't even manage to compile it (it
stopped compiling with a strange error message, namely an assembler
error message, that some alignment is not the power of 2; I tried both
this looks like the a.out vs ELF compiler problem. not surprising,
but see
Currently open questions include NetBSD's plans regarding gcc-3.
In particular, will the kernel be buildable with it soon? If not,
we may need to keep a kernel-gcc and kernel-ld for building kernels.
The kernel/gcc issue will probably get resolved soon enough. I wouldn't
What we really need here is a contact person... someone willing to go
to the NetBSD folks, explain to them what it is we want and how it can
halp what they want. We also need a contact person to organize
webspace, etc., from the Debian project. Now, some time ago, someone
What we really need here is a contact person... someone willing to go
to the NetBSD folks, explain to them what it is we want and how it can
halp what they want. We also need a contact person to organize
webspace, etc., from the Debian project. Now, some time ago,
program very often I'd say it's more hooked to glibc than to Linux from
what I could see.
Yes, I meant glibc. I am not that familar with NetBSD, so the process of
porting is quite long..
if you have problems with porting to NetBSD, please post about them to
this list. i
libstdc++ (NetBSD version)
I agree with the remark about GCC-3.0 here...
you will have issues using this compiler with some/most NetBSD ports. i
would strongly suggest using what we have as `src/gnu/dist/toolchain', which
is gcc 2.95.3 / binutils 2.11 based, and mostly works on
74 matches
Mail list logo
