re: glibc vs BSD libc
> 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 run 386bsd
> binaries on netbsd 1.5/i386. i just downloaded the netbsd/sparc 1.0
> /bin/sh and:
>
....
> i think you will find that netbsd cares _a whole lot_ about binary
> compatibility. to claim otherwise is simply fallacy.
Are you sure that running such old binaries doesn't require to have any
COMPAT_ option? I remember a recommendation on current-users that if you
upgrade your kernel before your userland, you should always compile the
COMPAT_xxx option for your previous version. I also vaguely remember
failure reports from people who forgot to do this.
i never said that you don't need COMPAT_XXX options. infact, i said
"is true that *any* old binary may require COMPAT_XX options in the
kernel". however, these options are enabled by default so unless you
actually take them out this isn't an issue. the advice you have
gotten from current-users is good and valid.
My statement of not caring about binary compatibility was wrong, sorry.
What I wanted to say was that the binary interfaces become incompatible
and compatibility is provided via COMPAT_ options in the kernel or by
packages containing old versions of librairies. So I really don't think
that it's possible to run an old binary against a new libc (at least,
the sonames wold probably mismatch). Why would otherwise the compat
packages in pkgsrc exist? Please correct me if I am wrong.
the compat packages exist to provide missing libraries. the netbsd
libc "soname" has never changed -- it was libc.so.12 when the first
ELF port arrived, and it is libc.so.12 today. of course you can not
use an ELF libc.so to run an a.out program. that's is what the compat
packages provide - a.out libraries so that old programs work. however
the a.out dynamic linker *is* provided by the system so given that
all relevant libraries are available, dynamic netbsd programs will
run back to when shared libraries were first introduced.
BTW, I believe there are some programs that search the kernel memory
directly for some data. Are ps and netstat examples of this? Can old
versions of such programs be successfully used on a new kernel, even if
the required COMPAT_ option is present? What about special ioctls, like
SCSI commands sent directly from userland?
ps(1) from netbsd 1.5 and above will work. programs like netstat and
other "kmem"/"libkvm" grovellers may or may not work. it all depends
on the relevant kernel structures not changing (too much?) kmem grovellers
do not count as "portable programs" -- they do not use published API's to
gather info, but assume a particular format about how the kernel stores
things. netbsd has been moving away from kmem grovellers in a big way
for two main reasons: the binary compat issue, and, most kmem grovellers
are set-id to group kmem. removing both of these issues *is* a goal, but
as i meantioned above, these sorts of programs don't "count" for backwards
compatibility. for instance, the VM system was completely replaced in
netbsd 1.4. no program that tries to grovel the old VM system could
possibly work today -- those data structures don't exist and more and in
many cases, they don't even have something comparable.
SCSI commands sent directly from userland i would expect to work. the
interface for doing this doesn't change, and the SCSI spec doesn't change
one hopes....
does this clear it all up? [sorry for being so verbose]
.mrg.
Reply to: