glibc vs BSD libc
Atifa Kheel
Content-Type: text/plain; charset=us-ascii
Content-Id:
Content-Disposition: inline
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.
Any comments??
thanx
Atifa
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--0-1750718527-1043067938=:73648
Content-Type: text/plain; name="Analysistxt.txt"
Content-Description: Analysistxt.txt
Content-Disposition: inline; filename="Analysistxt.txt"
1.
License
glibc :LGPL License
BSD libc:BSD
2.
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 _toupper() supported.
)
Berkely UNIX
(Eg:
BSD Signal handling
BSD wait
Symbolic links
Sockets
)
BSD libc supports:
ANSI C
pthreads as per POSIX.1 std
Berkely UNIX
3.
Portability
glibc:Portable to more than one Kernel and hence large
BSD libc:Don’t attempt to be portable across kernels and hence smaller.
4.
Error Reporting facility(Eg:perror,strerror)
glibc:Supported
BSD libc:Supported
5.
Memory Allocation
Basic Dynamic memory allocation (malloc () and free())
Changing the size of previously allocated memory(realloc()
Allocating and Clearing the memory (calloc())
Allocating aligned memory blocks (memalign() and valloc())
Storage allocation hooks (_malloc_hook, _realloc_ hook)
Obstacks(stack like allocation,generally not so much used to malloc)
Alloca
Reallocating allocator(GNU Extensions (r_alloc,r_alloc_free))
Heap Consistency Checking(GNU Extensions(mcheck,mprobe))
glibc: Supports All of the above
BSD libc: Supports all except Storage allocation hooks ,obstacks,reallocating allocator,
heap consistancy checking & valloc() is now obsolete with current malloc implementation which takes care for alignment on page size or larger allocations.
6.
Character Handling (tolower,toascii,etc)
glibc: Supported
BSD libc: Supported.
7.
a)String and array utilities
glibc: Supported
BSD libc:Supported except a few like strndup() and a few which are glibc specific like stpncpy,stpcpy are not Supported.
b)Collation functions
(strcoll,strxfrm)
glibc: Supported
BSD libc: Supported.
c)Search Functions
(memchr,strchr)
glibc: Supported
BSD libc: Supports except GNU extensions like memmem()
8.
a)Input/Output streams and Buffering:
glibc: Supported
BSD libc: Supported.
b)Line Oriented Input
glibc: Supported
BSD libc:Supported except GNU extensions like getline() and getdelim()
c)Formatted Output
(printf,sprintf,asprintf,etc)
glibc: Supported
BSD libc: Supported except obstack_printf() and obstack_vprintf()
d)Extend Syntax of printf template string (GNU extension)
glibc: Supported
BSD libc: Not Supported.
e)Other Streams(like string streams,Obstack streams,etc)
glibc: Supported
BSD libc: Not Supported.
9.
System call support
glibc: Supported
BSD libc: Supported.
10.
Support for Pipes and FIFOs.
glibc: Supported
BSD libc: Supported.
11.
File System Interfaces
glibc: Supported
BSD libc: Supported Except GNU extensions like getumask()
12.
Sockets Support
glibc: Supported
BSD libc: Supported.
13.
Terminal Interfaces (isatty,ttyname,etc).
glibc: Supported
BSD libc: Supported.
14.
Math Library
Support for Mathematical computation and trignometric functions.
glibc: Supported
BSD libc: Supported.
15.
Searching and sorting(eg:bsearch,qsort)
glibc: Supported
BSD libc: Supported.
16.
Pattern matching(eg:fnmatch)
glibc: Supported
BSD libc: Supported.
17.
Shell Style word expansion
(Eg:wordexp,wordfree)
glibc: Supported
BSD libc: Not Supported.
18.
Date and Time
glibc: Supported
BSD libc: Supported.
19.
Extended Characters
glibc: Supported
BSD libc: No multi-byte character set functions.Breaks building UTF(Unicode) support in libncurses.
20.
Locale and Internationalization
glibc: Supported
BSD libc:libintl and libiconv provides i18n support.By default libc does not contain –lintl.
21.
Signal handling
glibc: Supported
BSD libc: Supported.
22.
Process startup and termination
Program Arguments
(Eg:getopt)
Environment variables
Program Termination
glibc: All Supported
BSD libc:Supported.(getopt_long updated from NetBSD)
23.
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)
24.
User and Group Data base
glibc: Supported
BSD libc:Supported.Except a few functions like fgetpwent(),fgetpwent_r(),putpwent(),
Fgetgrent(),fgetgrent_r().
25.
System Information
glibc: Supported
BSD libc: utsname() not Supported.
26.
System Configuration parameters
glibc: Supported
BSD libc: Supported.
27.
Large file support
(fseeko64,ftello64)
glibc: Supported
BSD libc: Not Supported.
28.
Debugging features
(mtrace(memory leaks),backtrace,etc)
glibc: Supported
BSD libc: Not Supported.
29.
glibc: Add-on packages Crypt
BSD libc:Contains additional libraries like Libcrypt
--0-1750718527-1043067938=:73648--
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Dan Nelson
> 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
> Shell Style word expansion
> (Eg:wordexp,wordfree)
> glibc: Supported
> BSD libc: Not Supported.
wordexp/wordfree are in 5.0, so they will probably be backported to 4.*
at some point.
> 23.
> 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 not need to know about FreeBSD's shadow
password style, so that shouldn't really matter.
> 25.
> System Information
> glibc: Supported
> BSD libc: utsname() not Supported.
uname() is the correct function name (the data is returned in a struct
utsname), and BSD supports it.
> 27.
> Large file support
> (fseeko64,ftello64)
> glibc: Supported
> BSD libc: Not Supported.
BSD has supported large files far longer than Linux has. fseeko and
ftello are the functions you should use. fseeko64 is sort of redundant :)
--
Dan Nelson
dne...@allantgroup.com
Andreas Schuldei
> > 3.
> > Portability
> > glibc:Portable to more than one Kernel and hence large
> > BSD libc:Don’t attempt to be portable across kernels and hence
> > smaller.
>
> the distribution, I may agree, however, this does not speak to the
> size of the generated binary, which seems to me to be what you are
> referring to.
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.
Kris Kennaway
--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 a=
nd ancient utmp.
> > (Problem Solved by writing a library libshadow)
>=20
> User applications should not need to know about FreeBSD's shadow
> password style, so that shouldn't really matter.
5.0 has NSS. Also, while it's obvious you're coming from a Linux
background, please note that it's equally valid to consider glibc as
the one with the incompatible password file format ;-). What does
"ancient" mean, in technical terms?
Kris
--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+LHZyWry0BWjoQKURAk07AJ9Qw23zJiURBIHja+ZPD1qDBjSSBgCfUdqg
+VYrpF5mZfJ39FsOBJeb0BQ=
=u6hi
-----END PGP SIGNATURE-----
--AhhlLboLdkugWU4S--
Kris Kennaway
--2B/JsCI69OhZNC5r
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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 _toupper() supported.
If it's an 'extension', then it's not 'standard' and not worth using
as a point of comparison. Basically, most of the things you list as
"not supported" by BSD are better stated as being GNU-specific
extensions that are non-standard and therefore incompatible with the
rest of the world.
> 19.
> Extended Characters
> glibc: Supported
> BSD libc: No multi-byte character set functions.Breaks building UTF(Unicode) support in libncurses.
wide character support is present in 5.0.
Kris
--2B/JsCI69OhZNC5r
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+LHe0Wry0BWjoQKURAqn8AJ4z5+LYOrxR9Z3z8/ZcnTUCOoHzHACaAq8y
YYg+wOi20rkWnfspjxNuq1U=
=O1sK
-----END PGP SIGNATURE-----
--2B/JsCI69OhZNC5r--
David Brownlee
> 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 source or a binary level? A NetBSD 1.6 box can run NetBSD
1.0 binaries, complete with their shared libraries. A NetBSD
1.0 binary should even run against a NetBSD 1.6 libc (modulus
a.out or ECOFF changes to ELF).
--
David Brownlee - CTO Purple Interactive - (0)20 8742 8880
Pavel Cahyna
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 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.
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?
Bye Pavel
Jens Rehsack
>>Extended Characters
>>glibc: Supported
>>BSD libc: No multi-byte character set functions.Breaks building UTF(Unicode) support in libncurses.
>
> wide character support is present in 5.0.
>
/usr/include/. Also audio/id3lib compiles fine with the base system
(without devel/stlport), so I assume that 4.7 sometimes has a much
better wide char support than 5.0 ;-)
So long,
Jens
Kris Kennaway
--NQTVMVnDVuULnIzU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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.
Perhaps they wanted to hide implementation differences between
different OSes. Either way, the low-level functions in FreeBSD work
just fine.
Kris
--NQTVMVnDVuULnIzU
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+MEfjWry0BWjoQKURAhTGAJ4kJzdCsbhvSBuv+DBCsgOXUgnhqQCg1QYl
OhCqT1uQh9iiPC5xA/lXMFA=
=xIFm
-----END PGP SIGNATURE-----
--NQTVMVnDVuULnIzU--
Michael Ritzert
>
> 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.
Like in many other OSes, NetBSD switched from a.out to ELF. This has the consequence that
You need to add some kind of compatibility mode to support both formats - be it switchable (like in NetBSD or Linux) or not.
Michael
______________________________________________________________________________
Bequemer und billiger - SMS mit FreeMail verschicken! Mehr Information
unter: http://freemail.web.de/features/?mc=021147
Pavel Cahyna
> 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
Pavel Cahyna
> 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
So the ABI for libc didn't change since the introduction of ELF and
no compat librairies for ELF programs are not needed? This is new to me and
if is is so, it's very good!
> 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
Yes, I expected this...
> 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
This is very good too! What is used instead of kmem, is it sysctl?
>
> does this clear it all up? [sorry for being so verbose]
Thank you! Verbosity is a good thing.