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

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.

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.

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? 

Bye	Pavel



Reply to: