re: glibc vs BSD libc
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 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: russsian-intervention ~ uname -a NetBSD russian-intervention.eterna.com.au 1.6M NetBSD 1.6M (_russian_) #719: Sun Jan 19 00:15:13 EST 2003 [EMAIL PROTECTED]:/var/_russian_ sparc russian-intervention ~ file ./sh-sparc-1.0 ./sh-sparc-1.0: NetBSD/sparc demand paged executable russian-intervention ~ ./sh-sparc-1.0 $ ps PID TT STAT TIME COMMAND 229 p0 Ss+0:04.48 -tcsh 284 p1 Ss 0:02.16 -tcsh 327 p1 TN 178:29.44 systat -w1 vm 14305 p1 S 0:00.07 ./sh-sparc-1.0 14308 p1 R+ 0:00.06 ps 17424 p2 IWs0:02.76 -tcsh 22292 p2 SN+ 12:38.86 top ie, that is a netbsd/sparc machine running a kernel that is only a few days old, and it happily runs the 1.0 /bin/sh. (this is a SMP kernel with the new netbsd kernel-based userthreads implementation as well.) i can not test a dynamic program from 1.0 because i don't have the a.out libraries installed currently and i'm not bandwidth-connected right now to download them... (took long enough for /bin/sh to download!) however, i have in the fairly recent past (in the last year or so) run very old a.out dynamic sparc binaries on each of: - 32 bit sparc - 32 bit sparc64 - 64 bit sparc64 with 32 bit binary support when i was testing that the emulations work as LKM's. i think you will find that netbsd cares _a whole lot_ about binary compatibility. to claim otherwise is simply fallacy. .mrg.
re: glibc vs BSD libc
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 The funopen() functions first appeared in 4.4BSD. BUGS The funopen() function may not be portable to systems other than BSD.
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
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.
Re: glibc vs BSD libc
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 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. Bye Pavel
Re: glibc vs BSD libc
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 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
Re: glibc vs BSD libc
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 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
Re: glibc vs BSD libc
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 debian BSD to sum up the differences in BSD libc and glibc? What I have learned from this thread (and from porting apps from linux to NetBSD and Solaris): - there are differences between the libcs of these systems. - sometimes they hurt during ports, most of the time, they don´t hurt - the dominance of glibc-based linux has forced IBM and SUN to supply linux programming interfaces. This might happen in the BSD world in the future. - for the debian/BSD project on the sparc it seems to be better to stick to BSD libc (we keep in track with alpha and intel ports) So, coming back to the main topic: how did the NetBSD/intel people overcome these difficulties caused by bsd libc/glibc? greetings Michael __ Sie stehen auf POP3? Dann versenden Sie mit WEB.DE FreeMail Ihre SMS aus Outlook oder Netscape! http://freemail.web.de/features/?mc=021178
Re: glibc vs BSD libc
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 SUN to supply linux programming interfaces. This might Michael happen in the BSD world in the future. What's the significance of this ? Michael - for the debian/BSD project on the sparc it seems to be Michael better to stick to BSD libc (we keep in track with alpha Michael and intel ports) How come ? Michael So, coming back to the main topic: how did the Michael NetBSD/intel people overcome these difficulties caused by Michael bsd libc/glibc? Why would NetBSD/intel people care at all about glibc ? What difficulties they have ? ~velco
Re: glibc vs BSD libc
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: Supported Atifa BSD libc: Not Supported. Why is it important for debian BSD to sum up the differences in BSD libc and glibc? What I have learned from this thread (and from porting apps from linux to NetBSD and Solaris): - there are differences between the libcs of these systems. - sometimes they hurt during ports, most of the time, they don´t hurt - the dominance of glibc-based linux has forced IBM and SUN to supply linux programming interfaces. This might happen in the BSD world in the future. - for the debian/BSD project on the sparc it seems to be better to stick to BSD libc (we keep in track with alpha and intel ports) Er. Please do. It's insane enough already; tracking different libcs on different architectures of the same 'OS port' is liable to become flat-out insane. 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* wrapping them in suitable #ifdefs, or doesn't provide any alternative to them). Generally, at least so far, the patches are not terribly difficult, and we just submit them to the maintainer (and request forwarding it upstream, if applicable). Folks tend to be just fine with having their code be more portable if someone else is doing the scutwork of making it so. :) Honestly, I personally generally find far more difficulties in handling stuff that assumes a primarily glibc/Linux environment at the core (base-passwd and PAM spring to mind). These can also be fixed, but finding some sane and resaonable way is often non-trivial. Though the last I'd heard, the PAM maintainer was quite happy to work with us, as soon as we got to the point that we had the things it depends on, and I haven't really done much on base-passwd integration due to other issues (that is to say, base-passwd and PAM are some of the *least* critical, and in the case of base-passwd, I would prefer to patch our libc to handle things more like what Linux expects, instead of making base-passwd cope with pwdb stuff). -- Joel Baker [EMAIL PROTECTED] pgpyar0uDMrMe.pgp Description: PGP signature
Re: glibc vs BSD libc
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 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
Re: glibc vs BSD libc
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 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 [EMAIL PROTECTED]
Re: glibc vs BSD libc
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.
Re: glibc vs BSD libc
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 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 pgpcttXz4O8z7.pgp Description: PGP signature
Re: glibc vs BSD libc
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 pgpOdM9U8faHO.pgp Description: PGP signature
Re: Glibc on BSD?
On Sat, Aug 31, 2002 at 10:57:14PM -0400, Nathan Hawkins wrote: I haven't paid much attention to the BSD port, but I notice that glibc now includes support for FreeBSD again. Should I be tooling glibc up to produce libc1 packages for you? I've been tinkering with it for a while now. It works, but I've been having a lot of trouble with /usr/include/sys, trying to get things to the point where I can build some of the FreeBSD sources for /sbin. Okay. For now I'm assuming you don't want to be part of our getting-ready-for-2.3 process. If you do decide that you want to participate, let me know and I'll get the pieces added to glibc's control file for you so you can join in our testing. Tks, Jeff Bailey -- At last you cry out in anguish: Why me? God answers: Why not? - Sheldon Kopp
Re: Glibc on BSD?
Jeff Bailey wrote: On Sat, Aug 31, 2002 at 10:57:14PM -0400, Nathan Hawkins wrote: I haven't paid much attention to the BSD port, but I notice that glibc now includes support for FreeBSD again. Should I be tooling glibc up to produce libc1 packages for you? I've been tinkering with it for a while now. It works, but I've been having a lot of trouble with /usr/include/sys, trying to get things to the point where I can build some of the FreeBSD sources for /sbin. Okay. For now I'm assuming you don't want to be part of our getting-ready-for-2.3 process. If you do decide that you want to participate, let me know and I'll get the pieces added to glibc's control file for you so you can join in our testing. Hmm. Might as well add to the control file. It looks like freebsd-i386 will probably go with glibc. Do that whenever it's convenient. My testing is probably of limited help to the rest of Debian, since the FreeBSD port of glibc is new, and not really finished. Hopefully at some point I'll finish untangling /usr/include enough to be able to create some patches for glibc. I need to be able to build some of the BSD sources for /sbin and /usr/sbin, and at present there are a lot of things in the BSD includes that break with glibc. ---Nathan
