Android is also a UNIXy system. Kind of. With very much dumbed down standard library.

I very-frankly suggest that your quest for "POSIX compliant" is going to be a Faustian one: even if you succeed in doing it, it won't get your business the payoff that it imagines it's getting by specifying it.

I think that you should resign yourself to the fact that there will be a certain amount of "target platform specific" differences in your code, and that you should carefully design both the system and its Makefiles (and configure-scripts) to allow the same build-procedure to be carried out on any platform, even though the resulting source-code and build-steps will as a result vary somewhat from one platform to another.

For instance, go ahead and use cURL, because there is no reason to re-invent a wheel. Just make sure that you can see your way clear to running it on all your target systems, and do this be-fore you actually start building anything. That's key: the source-code that your developers write should vary very little.

You might also wish to explore some of the ideas in some platform-independent development systems such as haXe.

1 members found this post helpful.

If libs like zlib weren't POSIX-compilant / highly portable, they would never be so commonplace and used by everybody. Don't worry, established libs always run on virtually anything.

I appreciate your information, but in my present situation, I have to either see a claim that a library is POSIX compliant from its maker, or else, roll my own. There is no "probably" or "almost certainly" in what I'm doing.

Does a "POSIX-compliant" dependency in this case mean that it only depends on other libraries that are self-certified as POSIX-compliant? If so, I imagine you'll be rewriting everything that isn't included as a standard part of the operating system. So, given that you need to stop the quest at some depth, I suggest that depth be the software you're actually writing.

Kevin Barry

POSIX compliance is a matter of money, people usually care about dependencies, ie what you actually need to make the library work.

From the Debian FAQ:

Doesn't that only apply to the operating system, and not to 3rd-party software? There's really no value in certifying an application or library as POSIX-compliant unless it provides functionality that POSIX describes, but in such cases the standard applies to the behavior and API, not to the source code itself. This is highlighted by the fact that you can take POSIX-compliant C and translate it into asm, which isn't POSIX-compliant, yet when compiled into binary form it does the exact same thing. In my opinion, POSIX compliance of source code is more of an assurance to the maintainers that it's anticipated to compile and run on POSIX-compliant operating systems. Once it's compiled and linked, there's no telling if the source code was compliant or not; therefore, all value of compliance disappears once the software is in usable form.

Kevin Barry

In my case, what they want is a guarantee of nearly universal portability. This is a product that they hope to port to every platform and device, or, at least, that's the dream. I know that most platforms are just "Unixy" and not fully compliant, but this is their chosen approach to achieving something which almost runs in lots of different environments, even minimal ones. Hence my original desire to find a list of popular libraries already known to have been written in a POSIX compliant way. Every library which claims POSIX compliance is one I don't have to duplicate.

They are taking a wrong approach. I think they better stick to C++ 2011 standard and fully compliant compiler (I think LLVM).

I.e. I suggest in the needed libraries to replace potentially POSIX compliant functions with C++ 2011 standard library ones.

And don't forget about threads.

My point is that C++ 2011 appears to be a better abstractions layer than POSIX - because compiler vendors will be interested to make compliant compilers for their respective platforms.

I understand, but there is no C++ standard library replacement for zlib, libxml2, libcrypto, libssl, etc. My primary issue at the moment is the need to rewrite the portions of these and other libraries for my application. It's a lot of work. This is why I wanted so much to find a list of libraries which claimed POSIX compliance - to free myself from the need to redo as many libraries as possible.

We are going rounds.

By themselves zlib, libxml2, libcrypto, libssl have nothing to do with POSIX. But the libraries call standard "C" library functions which have to do with POSIX.

So, instead of pursuing POSIX compliance replace those standard "C" library calls with equivalent (or combination where needed) C++ 2011 standard library functions, thus making what you need to be C++ 2011 compliant.

If this is an option, then sticking with the existing versions of the libs in question should also be an option. This is because C++ 2011 isn't a standard part of an operating system; hence, it's a 3rd-party dependency like everything else.


If you end up rewriting libcrypto and libssl, I doubt many security-minded people will use your software. You'll also alienate a lot of users if you say, "You need to use my POSIX-compliant version of what you already have, even though you'll never know the difference."

In some cases, you might actually break the functionality of certain libs if you take out the non-POSIX code:

1. Think about inotify (Linux) and kevent (FreeBSD). Both are used to monitor files and directories for changes and there's no POSIX-compliant replacement, so if you removed them from a lib it would have to use a spinlock to replace that functionality.
2. The SIGLOST signal results in termination of a program in Linux, but that signal doesn't exist on FreeBSD. If you want to have a signal handler to perform cleanup, you'll have conditional code that's used on Linux but not on FreeBSD.
3. In some cases, a FreeBSD version of a library or program will have code that logs actions through the audit system.
4. POSIX doesn't describe SO_REUSEADDR for setsockopt, yet it can save everyone a lot of headache if a server process needs to be restarted immediately after it exits.
5. When changing the uid of a process in FreeBSD, it's often appropriate to set the login class and MAC label for security reasons. Failing to do so could create a major security hole, yet neither are POSIX concepts.

The point is that you can't just arbitrarily decide what code in your dependencies doesn't belong based on aesthetics.

Kevin Barry

An interesting discussion, but no one will ever be asked to use my libraries. They are alternatives for me to linking the existing libraries into my application. Also, I only implement the pieces I need. The sole goal is to write a POSIX compliant application. In addition to knowing which libraries claim POSIX compliance, I would like to know which libraries are nearly universally present, even on minimal platforms. I might be able to make a case for using non-POSIX compliant libraries if I could argue that we would find them in every location we contemplate installing this application. The goal is wide portability without change in functionality.

A library that is "nearly universally present" is of course also running on POSIX-compatible platforms.