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.
An
> "Atifa" == Atifa Kheel <[EMAIL PROTECTED]> writes:
Atifa> e)Other Streams(like string streams,Obstack streams,etc)
Atifa> glibc: Supported
Atifa> BSD libc: Not Supported.
wide oriented streams (wprintf, etc.) ?
Atifa> 14.
Atifa> Math Library
Atifa> Support for Mathe
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
> S
> 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.
glibc has fopencookie which is similar.
> 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 may agree, however, this does not speak to the
size of the
* 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 dis
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 applicati
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() a
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,
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
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.
On my 4.7-STABLE machine I took a look now is a wchar.h in
/usr/include/. Also audio/id3lib compiles fine with the
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.
P
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,
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 act
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:
HISTOR
>
> 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 386b
> 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 personal
Hello,
> 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 l
Momchil Velikov <[EMAIL PROTECTED]> schrieb am 20.01.03 15:20:56:
>
> > "Atifa" == Atifa Kheel <[EMAIL PROTECTED]> writes:
>
> Atifa> e)Other Streams(like string streams,Obstack streams,etc)
> Atifa> glibc: Supported
> Atifa> BSD libc: Not Supported.
>
Why is it important for d
> "Michael" == Michael Ritzert <[EMAIL PROTECTED]> writes:
Michael> Why is it important for debian BSD to sum up the
Michael> differences in BSD libc and glibc?
Maybe to justify choosing one or another ?
Michael> - the dominance of glibc-based linux has forced IBM and
Michael
On Tue, Jan 21, 2003 at 08:50:46AM +0100, Michael Ritzert wrote:
> Momchil Velikov <[EMAIL PROTECTED]> schrieb am 20.01.03 15:20:56:
> >
> > > "Atifa" == Atifa Kheel <[EMAIL PROTECTED]> writes:
> >
> > Atifa> e)Other Streams(like string streams,Obstack streams,etc)
> > Atifa> glibc: S
On Tue, Jan 21, 2003 at 09:42:55AM -0700, Joel Baker wrote:
> > So, coming back to the main topic: how did the NetBSD/intel people
> > overcome these difficulties caused by bsd libc/glibc?
>
> Most of the difficulties are non-portable code (such as code that uses GNU
> extensions *without* wrappin
Pavel Cahyna <[EMAIL PROTECTED]> wrote:
>
>Does somebody actually use funopen()? Does it really work?
Of course it works. It's used in the BSD version of compress(1) and in
libfetch, libftpio, and libz.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
ARDNAMURCHAN POINT TO CAPE WRATH I
23 matches
Mail list logo
