Fun with libc compile-time [re]configurationb

Most of the time when you write your C or C++ code on a modern UNIX platform you don't give much thought to the strict compliance with various standards which used to rule the disjoint UNIX landscape some odd number of years ago: XOPEN, POSIX, BSD, SVID, etc. And if an application has only the very same platform you're developing on as a deployment platform all is well. That doesn't happen all that often though. And once you face the neccessity of making sure that your application behavior is preserved across the variety of UNIX-like OSs there the fun begins. The biggest problem is that one of the cornerstone pieces of functionality every application on UNIX depends upon has the most colorful history behind it. Of course I'm talking about libc and the number of (sometimes conflicting!) APIs it has to offer in order to comply with various standards.

Now, not a lot of folks know this, but libc is highly configurable at an application compile time. If you have a reasonable compiler and a reasonable libc implementation you can ask libc to behave like it used to during the XOPEN times, BSD times or SVID times. The way you do that is usually via specifying macros like: POSIX_SOURCE, etc. Here's a complete list of macros you can tweak from the latest revision of Glibc:
from /usr/include/features.h:

   _ISOC99_SOURCE       Extensions to ISO C89 from ISO C99.
   _POSIX_SOURCE        IEEE Std 1003.1.
   _POSIX_C_SOURCE      If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2;
                        if >=199309L, add IEEE Std 1003.1b-1993;
                        if >=199506L, add IEEE Std 1003.1c-1995;
                        if >=200112L, all of IEEE 1003.1-2004
   _XOPEN_SOURCE        Includes POSIX and XPG things.  Set to 500 if
                        Single Unix conformance is wanted, to 600 for the
                        upcoming sixth revision.
   _XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions.
   _LARGEFILE_SOURCE    Some more functions for correct standard I/O.
   _LARGEFILE64_SOURCE  Additional functionality from LFS for large files.
   _FILE_OFFSET_BITS=N  Select default filesystem interface.
   _BSD_SOURCE          ISO C, POSIX, and 4.3BSD things.
   _SVID_SOURCE         ISO C, POSIX, and SVID things.
   _GNU_SOURCE          All of the above, plus GNU extensions.
And it should be quite straightforward to realize that once you add something like this to your compilation line you're essentially changing behavior of quite a few APIs (and YES! things can break or stop working at all):
    $ cc -D_XOPEN_SOURCE=500 application.c
What is much less straightforward is the fact that vendors slice and dice what they give you by default at their pleasure. For example GCC always defines _GNU_SOURCE which means that by default you're getting much more non-standard functionality than would otherwise be available (and yes! sometimes getting more than you've asked for is a portability nightmare). And when you move your application to a place where the defaults are different you have to fish out for the interfaces you need and how to enable them. What's even more important is that you have to constantly be on a lookout for different standards implementing some of the interfaces a little bit differently. Which means that if vendor A decided to give you an API which happens to be part of the larger standard by default, there's no guarantee that when you go to a platform where that single API is not available unless you explicitly ask for the standard it is part of other thing won't break.

Now, personally, I got bitten by it when I was porting an application from Solaris to Linux and got bitten by the fact that a very simple and unassuming call to sigset(2) was, in fact, part of the larger XOPEN standard and was not available on Linux by default unless you ask for it. On Solaris, however it is. So the dilemma I was faced with was either to augment my compilation line with something like: -D_XOPEN_SOURCE=600 (which I knew would break a couple of other things) or fish for something else that would only enable the sigset.

I ended up doing -D_XOPEN_SOURCE=600 and fixing the other stuff.

I think these blog is really useful for new comers and Excellent resource list. It´s a very interesting Blog and simple answer of many questions. Keep up the good work! Thanks it helps me a lot…

Posted by Onlineshop on March 23, 2007 at 01:33 PM PDT #

Why is the XOPEN available in Solaris and not in Linux? Normally I would think it would be the other way around and it confuses me to no end to think that Solaris has better capabilities in this capacity than Linux does. Also, I wasn't around for the strict standards that UNIX used to impose on coders and users alike so I"m unfamiliar with many of the terms you listed there. Care to explain what their purpose was? Also, while we're on the topic of strict standards how do you feel about the movement for standardization across the entire web that some people are really pushing for? I mean, if you were excited that UNIX was getting rid of some of its more stringent practices then you have to hate this new movement that would force everyone to pretty much redesign every element of their web sites, right? And if you're for it, can you provide an argument as to why you're pro-web standards and con UNIX standards?

Posted by cheap digital cameras on July 30, 2007 at 09:33 AM PDT #

To: cheap digital cameras

It is possible to get to XOPEN on both platforms, the key question is what are the defaults. Unfortunately, on Linux the answer to this question depends in part of what compiler gets used. Glibc enables quite a few things if it sees that the application gets compiled by GCC. Which in my opinion is wrong: [g]libc headers should be as compiler neutral as possible.

As for explaining all the various standards I really suggest you take a look at the OpenGroup history hub:
and especially this page:

Your last question on standardization is a tough one. These days I don't really whether to like standards or to hate them with the same passion I used to. But I still think that the only thing nice about standards is that we have so many of them to choose from ;-)

Posted by Roman Shaposhnik on August 14, 2007 at 06:24 AM PDT #

I haven’t tried working on this through Solaris. Although I’m not part of the tech team, I’m pretty sure that they’re doing well and they haven’t encountered any problem.

Posted by pet portraits on December 27, 2007 at 04:50 PM PST #

Here are many useful informations in this article. Thanks and greatings from Thuringia!

Posted by Kunst on January 10, 2008 at 12:02 AM PST #

There are many useful informations in this great article…I really enjoy reading the whole blog that you write. Thanks

Posted by übersetzungen on February 03, 2008 at 07:08 AM PST #

An excellent resource for those who are working on project requiring the use of C or C++ for code-writing!

Posted by fine art paintings on March 27, 2008 at 01:57 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed



Top Tags
« July 2016