Is NPTL from glic source tree the canonical libpthread distribution for pthread?
Want to make sure because there's also an ambiguous libpthread named project hosted on Hurd.
There is no such thing as "canonical libpthread" -- it is different on different platforms.
On Linux, GLIBC provides POSIX thread implementation as part of it (in the nptl directory), and that's what most Linux programs use. But it's possible to use other C libraries (uClibc, dietlibc, Musl), and they provide their own thread implementation. It would generally not work to try to link NPTL with Musl (or any other non-GLIBC libc implementation).
On Solaris, or AIX, or HP-UX, the POSIX thread implementation is completely different and has nothing to do with NPTL (or any other open-source implementation).
there's also an ambiguous libpthread named project hosted on Hurd.
That looks like a fork of GLIBC with Hurd-specific patches.
Related
One of the Units of Functionality that POSIX states an OS needs to provide to be POSIX compliant is POSIX_C_LANG_SUPPORT. Basically this is the whole C Standard Library with some more things.
My question is simple: developers of POSIX compliant OSes usually just download an open source version of C Standard Library (e.g. glib or uClibc) and adapt it to fit POSIX or they implement everything from scratch? Is there any advantage in rewriting the C Library instead of just picking one of the very known implementations and adjust it to my needs?
Really, it is done in the inverse way.
We have different Unix versions: two main families: SystemV and BSD, different manufacturers, and so there was a need to standardize. US government wanted also standardized programs, so POSIX (version 1) was created, by standardizing OS interfaces (a step further than just C standard).
Windows NT is also POSIX (version 1) compatible, just because government wanted standardized tools. So POSIX was designed very very broad.
Then with time, there were need to standardize some more Unix (and similar) systems. Not as just one system, one API, but as common API, and so programs (e.g. GUI libraries or databases) could eventually use extension, but also make sure that program that follow the standard works on compatible system.
This was SUS (Single Unix Specification). This required a UNIX like system (unlike POSIX 1).
Then POSIX became not so important: application that in theory could work on all POSIX systems didn't really work on POSIX Windows.
So the new version of POSIX merged old POSIX plus SUS plus new useful function missing in SUS.
Now Linux is important, so Linux implementations (e.g. glibc) is taken into account when updating POSIX. You will see in the mailing list, that POSIX is defined by "vendors" of different Unix and similar systems.
So, it is not that operating systems extend POSIX, it is just that POSIX takes the most useful and standard options from different OS. It creates new interfaces just when existing interfaces are so incompatible, that by standardizing, it will break existing programs.
For the "second" question: when you develop a new operating system, you choose what way to go. Usually it is just derivation and fork (and distributions): again from the two Unix families, of just deriving Linuxes from RedHat or Debian). Sometime system is build from scratch, because of the design. Kernel provides most of system calls, so e.g. glibc needs a lot of systemcall (given by kernel) implemented in a similar way as POSIX. Glibc is not complete. Note: early Linux distributions used other libraries. GLibc was also written from scratch.
Well, we are all dwarves standing on the shoulders of giants.
Writing a new OS is a huge undertaking, so the wise one will re-use whatever (design, libraries, compilers, other software) they can. It's still in all likelyhood far too much work, so why make it even harder by rewriting everything from scratch?
I'm trying to cross-compile an SSH-server to port it on an home-made OS, using newlib (because the OS uses a lib which is based on newlib).
I got some troubles with the RedHat Newlib, and I was wondering if I can do my porting with another library (for example uclibc) ?
Is there differences between this 3 "libc" interfaces (libc, newlib, and uclibc) ?
GNU libc (glibc) includes ISO C, POSIX, System V, and XPG interfaces. uClibc provides ISO C, POSIX and System V, while Newlib provides only ISO C.
While you might be able to port other libraries, they have specific OS dependencies. Unless your OS itself is POSIX compliant, it will probably be an unrealistic prospect.
Even with Newlib, it is your responsibility to implement the syscalls appropriately to support devices, file-systems and memory management.
main difference is the size of the library, uclibc and newlib are focused on embedded systems so they want to be small and fast, while glibc is focused in full functionality.
so basically there might not be all functions in the embedded versions, but the standard c interfaces should be same in all c libraries. the datatypes might be different, especially names of fields in a structures are often not standardized.
I was wondering whether anybody here could help me better understand the relationship between OSX and C. There's some developer information related to C++ in xcode but nothing for C.
I believe one fundamental difference is that osx uses libc as opposed to glibc. Can anybody point me to libc documentation? I can't seem to find any.
I've seen the usr/includes folder but all that does is make me wonder where I can get a reference that elucidates all the options available to me. For instance, I just discovered <tree.h>. That's all well and good but is there any documentation? Or do I need to trawl the includes folder?
It seems that you're asking whether the functionality that OSX provides to you as a programmer is partially different from other *nix systems; focusing on the functionality that OSX's implementation of the C Standard Library provides you with.
Now keep in mind that while the C Standard Library is a very common way to take advantage of the functionality the operating system kernel exposes, it's not the only way. You can use other low-level libraries, or write low-level functions yourself.
Having said that, consider the following:
OSX, like many other *nix systems, is "mostly POSIX-compliant". Meaning that its particular C Standard Library implementation will likely expose headers defined by the POSIX standard. This is the stuff you can rely on regardless of whether you use libc, glibc, or some other implementation of the C Standard Library.
Depending on the particular C Standard Library you're using, it might come with additional functionality, like BSD libc - we say "superset of the POSIX Standard Library" to that. While it can contain implementations of things specific to BSD (and therefore OSX), it mostly seems to contain things that can be implemented regardless of the operating system flavour. For example, the sys/tree.h header that you mention is "an implementation of Red-black tree and Splay tree" - by no means something that couldn't have been implemented on a Linux system!
To sum up:
OSX comes with an implementation of the C Standard Library called BSD libc that provides some additional headers on top of what the POSIX Standard defines.
The difference in functionality between the XNU kernel used by OSX and other *nix kernels will not necessarily be captured in the difference between the C Standard Library implementations. If you want to know what the XNU kernel can do for you that the Linux kernel can't, the place to start is with the kernels themselves.
So your question can be split into:
What is the difference between glibc and BSD libc?
and
What is the difference between the XNU kernel and the Linux kernel?
It's a bit unclear what you're asking.
OS X is based on top of FreeBSD, a POSIX-compliant UNIX operating system. The relationship between OS X and C is that C is one of many programming languages that you can code in to develop for the platform (C is the core of Objective-C, an otherwise unused language that Apple champions).
OS X doesn't use libc. clang, the compiler that ships as part of Apple's developer tools package for OS X, uses libc. There's a difference. If you want to use glib, grab GCC from Homebrew or Macports and use it to compile your programs instead of clang.
Lastly, you can't find documentation for libc, as all C libraries, like libc, glibc, etc, all provide the same set of functions if they are standards-compliant. There tend to be few differences end-user-wise between the different C libraries; so, if you want to find out about a header file, use man, like this: man clang to read clang documentation, for example.
Hope this helps.
When we debug a program using gdb, we usually see functions with strange names defined in libc(glibc?). My questions are:
Is libc/glibc the standard implementation of some standard C/C++ functions like strcpy,strlen,malloc?
Or, is it not only of the first usage as described above, but also an wrapper of Unix/Linux system calls like open,close,fctl? If so, why can't we issue syscalls directly, without libc?
Does libc only consist of one lib (.a or .so) file, or many lib files (in this case, libc is the general name of this set of libs)? Where do these lib file(s) reside?
What is the difference between libc and glibc?
libc implements both standard C functions like strcpy() and POSIX functions (which may be system calls) like getpid(). Note that not all standard C functions are in libc - most math functions are in libm.
You cannot directly make system calls in the same way that you call normal functions because calls to the kernel aren't normal function calls, so they can't be resolved by the linker. Instead, architecture-specific assembly language thunks are used to call into the kernel - you can of course write these directly in your own program too, but you don't need to because libc provides them for you.
Note that in Linux it is the combination of the kernel and libc that provides the POSIX API. libc adds a decent amount of value - not every POSIX function is necessarily a system call, and for the ones that are, the kernel behaviour isn't always POSIX conforming.
libc is a single library file (both .so and .a versions are available) and in most cases resides in /usr/lib. However, the glibc (GNU libc) project provides more than just libc - it also provides the libm mentioned earlier, and other core libraries like libpthread. So libc is just one of the libraries provided by glibc - and there are other alternate implementations of libc other than glibc.
With regard to the first two, glibc is both the C standard library (e.g, "standard C functions") and a wrapper for system calls. You cannot issue system calls directly because the compiler doesn't know how -- glibc contains the "glue" which is necessary to issue system calls, which is written in assembly. (It is possible to reimplement this yourself, but it's far more trouble than it's worth.)
(The C++ standard library is a separate thing; it's called libstdc++.)
glibc isn't a single .so (dynamic library) file -- there are a bunch, but libc and libm are the most commonly-used two. All of the static and dynamic libraries are stored in /lib.
libc is a generic term used to refer to all C standard libraries -- there are several. glibc is the most commonly used one; others include eglibc, uclibc, and dietlibc.
It's the "standard library". It's exactly like "MSVCRTL" in the Windows world.
The Gnu standard library ("glibc") is the implementation of libc most commonly (almost universally?) found on Linux systems. Here are the relevant files on an old SusE Linux system:
ls -l /lib =>
-rwxr-xr-x 1 root root 1383527 2005-06-14 08:36 libc.so.6
ls -l /usr/lib =>
-rw-r--r-- 1 root root 2580354 2005-06-14 08:20 libc.a
-rw-r--r-- 1 root root 204 2005-06-14 08:20 libc.so
This link should answer any additional questions you might have (including references to the full and complete GLibc source code):
http://sourceware.org/glibc/wiki/HomePage
You can check the detailed information about "libc" and "glibc" from the man pages on your linux sytem by typing "man libc" on the shell, copied as below;
LIBC(7) Linux Programmer's Manual LIBC(7)
NAME
libc - overview of standard C libraries on Linux
DESCRIPTION
The term "libc" is commonly used as a shorthand for the "standard C library", a library of standard functions that can be
used by all C programs (and sometimes by programs in other languages). Because of some history (see below), use of the
term "libc" to refer to the standard C library is somewhat ambiguous on Linux.
glibc
By far the most widely used C library on Linux is the GNU C Library ⟨http://www.gnu.org/software/libc/⟩, often referred
to as glibc. This is the C library that is nowadays used in all major Linux distributions. It is also the C library
whose details are documented in the relevant pages of the man-pages project (primarily in Section 3 of the manual). Doc‐
umentation of glibc is also available in the glibc manual, available via the command info libc. Release 1.0 of glibc was
made in September 1992. (There were earlier 0.x releases.) The next major release of glibc was 2.0, at the beginning of
1997.
The pathname /lib/libc.so.6 (or something similar) is normally a symbolic link that points to the location of the glibc
library, and executing this pathname will cause glibc to display various information about the version installed on your
system.
Linux libc
In the early to mid 1990s, there was for a while Linux libc, a fork of glibc 1.x created by Linux developers who felt
that glibc development at the time was not sufficing for the needs of Linux. Often, this library was referred to
(ambiguously) as just "libc". Linux libc released major versions 2, 3, 4, and 5 (as well as many minor versions of those
releases). For a while, Linux libc was the standard C library in many Linux distributions.
However, notwithstanding the original motivations of the Linux libc effort, by the time glibc 2.0 was released (in 1997),
it was clearly superior to Linux libc, and all major Linux distributions that had been using Linux libc soon switched
back to glibc. Since this switch occurred long ago, man-pages no longer takes care to document Linux libc details. Nev‐
ertheless, the history is visible in vestiges of information about Linux libc that remain in some manual pages, in par‐
ticular, references to libc4 and libc5.
I am learning(just finished) C+Algorithms and am a newbie. I wanted to know if the POSIX Linux API is used on a Mac. Linux has functions like pread pwrite readv writev nftw symlink pipe popen posix_self sigprocmask sigaction (system calls). Does the Mac have the same API?? I heard that OS-X is based on a BSD kernel so i was wondering if i could use code written on Linux on OS-X if i stuck to using only POSIX functions. How similar is the OS-X API to the Linux POSIX/SUSv3 API??
The Wikipedia article on POSIX has a section dedicated to compliance. Short answer: yeah, it's going to have all the POSIX functionality you're likely to come up against. And it will probably have more (e.g. a lot of BSD apis that might not actually be POSIX)
If you're asking if you can write code that works on both platforms, the answer is yes. If you're asking if that's easy, the answer is probably no.
POSIX is not a Linux standard, but Linux follows it, as does OSX, BSD, HPUX, Solaris, and even some real time operating systems like QNX (just to name a few).
If you program to a POSIX API as much as possible, porting your code will be much easier.
They're close. There are some BSD things you won't find in Linux, and some Linux things you won't find on BSD. You can nearly always restrict yourself to a subset which is compatible with both platforms without much trouble. POSIX APIs which are not portable are often given the _np designator. You'll also find some things are not (yet) supported on one platform. There is a safe middle ground in the more established APIs. And this can of course vary by which OS versions you are targeting. Implementations may vary slightly if you wander into less common APIs. My first stop is to check the man pages.