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
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
Hello,
some notes about NetBSD libc:
it supports nsswitch for a long time, see here:
http://netbsd.gw.com/cgi-bin/man-cgi?nsswitch.conf++NetBSD-current
Dynamically loaded NSS modules are not supported.
To David Brownlee: I doubt NetBSD 1.0 binary could run against
a NetBSD 1.6 libc. They
On Thu, Jan 23, 2003 at 06:41:27PM +0100, Pavel Cahyna wrote:
And, if there are things like funopen(), why do Gnome hackers invent
their own APIs like gnome-vfs? Does somebody actually use funopen()?
Does it really work?
They presumably did it because they thought it would be a good idea.
Pavel Cahyna [EMAIL PROTECTED] schrieb am 23.01.03 19:14:41:
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
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
On Mon, 20 Jan 2003, Andreas Schuldei wrote:
i understood him this way: glibcs *portability* is large, since
it is not only portabel over several archs but also over several
kernels.
bsds libc is less portable (only accross different archs) so its
portability is smaller.
At a
Hello,
I am trying to study the various functionalities
supported by glibc Vs presence or absence of those
features in BSD libc.
This information here is w.r.t BSD libc which is
supplied with FreeBSD4.6(on intel)
i would like to know if i am missing something or some
information is not accurate.
In the last episode (Jan 20), Atifa Kheel said:
e)Other Streams(like string streams,Obstack streams,etc)
glibc: Supported
BSD libc: Not Supported.
BSD supports funopen() which allows the user to create handles for
arbitrary stream types.
http://www.freebsd.org/cgi/man.cgi?query=funopen
* Neal H. Walfield ([EMAIL PROTECTED]) [030120 19:10]:
3.
Portability
glibc:Portable to more than one Kernel and hence large
BSD libc:Dont attempt to be portable across kernels and hence
smaller.
I do not see the logic. If you are speaking about lines of code in
the distribution, I
On Mon, Jan 20, 2003 at 10:31:31AM -0600, Dan Nelson wrote:
System database and name service switch(NSS)
glibc: Supported
BSD libc: NSS not supported.Incompatible shadow and password support and ancient
utmp.
(Problem Solved by writing a library libshadow)
User applications should
On Mon, Jan 20, 2003 at 05:05:38AM -0800, Atifa Kheel wrote:
Some other comments:
glibc support for standards:
ANSI C(ISO C)
POSIX (Pthreads support)
SYSTEM V
(Eg:
Malloc tunable parameter(mallopt)
Extensions :
Statistics for storage allocation with malloc(mallinfo)
_tolower() and
13 matches
Mail list logo