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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: glibc vs BSD libc
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 msg16499/pgp0.pgp Description: PGP signature
Re: glibc vs BSD libc
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 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
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] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: glibc vs BSD libc
* 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 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
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 msg16119/pgp0.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 msg16121/pgp0.pgp Description: PGP signature
