5

I am writing a C program with POSIX API and using Linux. I compiled and ran it on a friend's Mac OSX PC and there was a small error, but I did not use Linux specific features.

I will use some specific features that Linux adds to the API. I will also use specific POSIX extensions for Mac Os X and FreeBSD.
I will use conditional compilation to choose the code. If the OS is none of those, I will use generic POSIX code.

I do not own Darwin/Mac OSX and FreeBSD, Linux is the only OS that I have in my PC. I cannot download and install FreeBSD, because it is more than 500 MB.
I want to know a way to test if the program will compile and behave as expected on other POSIX systems.
I wonder if there is a POSIX simulator and compiler to do tests.
The tests are simple, they do not use GUI and drivers, they are only command line.

I will need to do 3 tests: FreeBSD, Mac OSX/Darwin and Generic POSIX, but I do not have the tools.

EDIT

Is there a minimal version of FreeBSD and Darwin without GUI, but with GCC/G++ and ssh/scp? Darwin is free, is not it?
My PC is old, but I think I can install them in a virtual machine, create a virtual network and use ssh/scp to transfer and test the programs.

Squall
  • 4,344
  • 7
  • 37
  • 46
  • 6
    It is something of a cliche, but 'there is no portable code; only code that has been ported'. There is no substitute for having the systems to test on. Failing that, you have to code to the subset of the standard that you can rely on the different systems having. Avoiding conditional compilation is best; it complicates life if you have to use it. – Jonathan Leffler Apr 28 '12 at 23:05
  • 1
    @Jonathan: While that's true to some extent, it's become a lot less so over the past 5-10 years, to the point where lots of the traditional things people did for the sake of "portability" to "oddball systems" now seem like antiquated cruft. I agree there are arguments to be made on both sides, but I think coding to standards and pestering implementors to fix their broken implementations when they don't conform to the standards has a lot of merit as a way of pushing forwards towards a future where we don't have to play the "port to every target" game. – R.. GitHub STOP HELPING ICE Apr 29 '12 at 01:32
  • 2
    It also has a lot more success when the big players get on board. From the other side, GCC's cracking down on lots of UB (like signed overflow and aliasing violations) did break things at first, but it's gone a long way towards getting programmers to fix their broken programs. Some similarly bold action from the application side by big-name applications could have big effects. By the way, taking this approach doesn't necessarily mean your program won't run on popular broken platforms. It just means you have to supply the fix/glue layer to make your standards-targetted code run there. – R.. GitHub STOP HELPING ICE Apr 29 '12 at 01:35
  • Since the questionner will 'use some specific features that Linux adds to the API', the code will presumably not behave the same everywhere, at least not without extra work to provide the features from the Linux extensions. I think that dual booting or VM-running FreeBSD should be relatively straight-forward (so not being able to test on FreeBSD is blinkered); Mac OS X is more problematic. It does depend on what features are going to be used; you can do an awful lot portably without conditional compilation. – Jonathan Leffler Apr 29 '12 at 02:06

2 Answers2

6

One simple way is to compile your program with the proper feature test macros. For example if you define _POSIX_C_SOURCE to the target version of POSIX (currently 200809L), you will request the system headers expose to your program nothing except what's needed/allowed by POSIX base. This can be done via the command line CFLAGS with -D_POSIX_C_SOURCE=200809L. If you want the XSI option (full Single Unix Standard functionality, which is a superset of POSIX base) then use -D_XOPEN_SOURCE=700 instead.

This will not help you detect problems that come from either certain systems lacking POSIX functionality (for example, OSX is broken and lacks a working sem_init last I checked, even though it's mandatory in POSIX), or from writing code that depends on non-standard behavior in the POSIX-standard interfaces (for example, using GNU regex extensions in the expressions you pass to regcomp) but it will help you catch any accidental usage of interfaces not in the standard.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • With regards to OS X - http://stackoverflow.com/questions/1413785/sem-init-on-os-x. Compiles, but returns an error on unnamed semaphores. – dsolimano Apr 29 '12 at 00:46
  • Thanks for the link. This is really unfortunate since (unnamed) semaphores are one of the most useful synchronization tools POSIX offers (especially their ability to be used from signal handlers), whereas named semaphores are rather clunky, pollute a global namespace, and can get left behind if you terminate unexpectedly... – R.. GitHub STOP HELPING ICE Apr 29 '12 at 01:38
1

If you want to compile for other system, you usually don't need to have the other system, you just need an appropriate cross compiler.

MByD
  • 135,866
  • 28
  • 264
  • 277