I am learning network programming through the sample source codes from this link http://cs.baylor.edu/~donahoo/practical/CSockets/textcode.html. During the compilation, just wondering why in Solaris environment, i have to manually link socket and nsl library in the make file but when in the linux machine, i dont need to do that ?
Documentation used: http://developers.sun.com/solaris/articles/solaris_linux_app.html
This is because linux's libc, the glibc (-lc, which is linked by default to all programs) includes socket part of POSIX; and nis/nis+ dynamic libraries in linux are loaded dynamically by libc too.
But in Solaris, there are a lot of libraries with basic functionality, which are not in libc.
(libc, libucb, libmalloc, libsocket, libxnet, etc). I think, it was a design solution to allow user link only parts of API he needs.
In linux there are some basic libraries outside libc too: libaio, librt, libm.
With separate library it is easier to update only some parts of system; and it is possible to have several implementations (e.g. to provide greater compatibility/workarounds with older versions of UNIX) of some libraries coexisting in same system.
This question is discussed a lot, e.g. http://web.archiveorange.com/archive/v/KcxCHdLNpD6NANxmAt3b http://mail.opensolaris.org/pipermail/opensolaris-code/2007-January/010316.html
are seriously considering folding libnsl and libsocket into libc.
It would be nice to move ONLY the current POSIX-based and other
standards-based functionality (Unix98 etc.) libnsl+libsocket functions
to libc and keep all the compatibilty-wrapper stuff in libnsl/libsocket
to avoid that libc gets bloated with 20years of Unix
backwards-compatibility workarounds
Because in Linux, the entire networking API is implemented in libc.so which is linked into every C program by default, while in Solaris, its implemented in separate libraries.
Related
I'm compiling a Linux toolchain based on Newlib for a toy project.
Newlib's official page reports:
Newlib is a C library intended for use on embedded systems.
but without providing any particular reason.
What I'm trying to figure out is:
Why newlib consider itself embedded "only"?
What are the downsides to use it on desktop or server environments?
Unlike Glibc, which has very specific code to make sure that it is replaceable with later API compatible versions, the Newlib isn't so; nor does it support dynamic linking anyway. And it doesn't make much sense to statically link in the C library in every possible executable in a desktop environment. Therefore, Newlib is mostly suitable for embedded targets with small number of statically linked executables.
Newlib also fulfils only the parts of the C standard library and a a minimal part of the POSIX C library extensions. Specifically it doesn't concern itself with networking at all. It is somewhat debatable if anyone in their right mind, would want to build a desktop system without any networking at all, in 2017.
Another thing to note is the non-technical aspect of licensing. Glibc uses the LGPL license, which does allow linking against proprietary programs, provided that (note that IANAL) the user is able to replace the LGPL-licenced library with another one. In practice this means that either the library is dynamically linked in, or, in case of a statically linked library, the user is provided with object files that they can use to link against the replacement library to produce an executable. This means that the license itself might not be suitable for small embedded systems with proprietary software. Newlib doesn't contain any LGPL code, unless it is built for Linux targets.
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.
Sometimes, I want to know the implementation of a c function. My editor is vim. I have try ctags and cscope, and man.
man 2|3 only tell me how to use a function.
Both ctags and cscope can just find some of the implementation of functions.
They all can't find some functions. especially some system function(calls).
If a function can be use by include some header file, is there any way easily find the implementation of a function,
select(2) is a system call (but I suggest using poll(2) instead - google for C10K problem to understand why I prefer poll over select). So it is really implemented inside the linux kernel. The libc contains a small stub function (translating the C argument convention to the syscall convention, then doing the real syscall with e.g. some SYSENTER machine instruction). You could look into the source code of MUSL Libc (I recommend MUSL libc because its source is much easier to read) or the real Gnu libc to see that wrapper function.
FD_SET is just a macro, defined in /usr/include/x86_64-linux-gnu/sys/select.h and really in /usr/include/bits/select.h
But you are very right to try to find out how software functions of Linux are implemented: take advantage that it is free software.
Actually, the syscall layer is well defined and quite stable (see the syscalls(2) man page, and read Advanced Linux Programming for more. Look also for the Posix standards). It is much more interesting to study the source code of higher-level libraries using them (e.g. Qt, Gtk, ...).
From an application's point of view, syscalls are elementary "atomic" operations. strace is a handy utility to find which syscalls are done by some process (or running program).
You won't get around pulling in the sources of the module providing the function's implementation.
For Linux most of the modules in use are open source, so access to the sources shall be possible.
Where to get the sources from depends on library and/or the distribution in use. This includes the kernel.
There are distributions which may include all sources. Gentoo is one of those.
For Debian based distros it is easy to pull a package's sources using the apt-get tool:
$ apt-get source <package-name>
Other distros may use other ways to provide sources. Perhaps fellow SO experts might like to comment/answer regarding those.
I am using a custom user space environment that has barely no OS support: only one char device, mass storage interface and a single network socket.
To provide C programming to this platform, I need a libc. Is there any libc project that is configurable enough so that I can map low-level IO to the small API I have access to ?
AFAIK glibc and uclibc are expecting linux syscalls, so I can't use them (without trying to emulate linux syscalls, which is something I prefer to avoid).
There are several different libc's to choose from, but all will need some work to integrate into your system.
uClibc has a list of other C libraries.
The most interesting ones on that list are probably
dietlibc
newlib
FreeDOS has a LIBC
EGLIBC might be simpler to port than the "standard" glibc.
newlib might serve this purpose.
Is it possible to have glibc and uClibc based applications running side-by-side on one system?
Background: We have binary gcc based cross-compiler configured to link with uClibc. We have cross-compiled glibc with it. Now we want to build some applications so they will link with the glibc rather than uClibc. We don't want to rebuild the compiler.
There's no problem with glibc and uClibc living side-by-side with some programs linking to one and other programs linking to the other. However, there is a problem with additional libraries. Each shared library on your system will be built against either glibc or uClibc (using the corresponding headers, which define distinct ABIs for the standard library functions), so for example if both a glibc program and a uClibc program need ncurses, you'll need to have two versions of ncurses built, and have a way of ensuring that the correct one for the given program gets loaded at runtime. Alternatively, you could choose to only use one set of shared libraries, and use static libraries for programs linked to the other libc, but you'd still need to build your 2 sets of libraries.
Yes, it should be perfectly possible, but you might have to play around with LD_PRELOAD_PATH. If you are linking statically, change to dynamic linking.
It is nearly impossible to mix them in the same FHS, as the ABI and include dir are incompatible. However, you could install either of them in an directory offset, by tweaking dynamic-linker field in ELF and exploiting sysroot feature in gcc/binutils. An on going experiment is in Gentoo community[1], known as Prefix/libc.
http://wiki.gentoo.org/wiki/Prefix/libc