I run little scientific scripts and C tools on OS X from time to time. For the C tools, I just download the source and compile using the provided Makefile. I usually don't have any problems when using the tools.

However, knowing that those tools were written on Linux most of the time, I wonder if the differences in architecture (Linux is System V based, OS X is BSD based) will present issues.

  • What kind of scripts and C tools? Scientific hardly describe them. Is it X11, do they use vector engine, etc. Anyway, usually I just run a VM instead of worrying.
    – imel96
    Commented Jul 7, 2014 at 22:57
  • @imel96 Well, imagine me downloading the Linux source (when there is no OS X version), then ./configure <-> make ... or gcc blahblah.c blahblah.h -o blahblah. I do that a lot. Again, it doesn't seem to pose problems for me, but since science demands accuracy, it would good to know what the differences in architecture, so I can determine when I should not do what I'm doing.
    – William
    Commented Jul 8, 2014 at 3:21
  • If it compiles and runs fine then it should be okay. But if you concern about the accuracy of their output then nothing is sure until they passed some test. Some programs include 'make test' to check for these things.
    – imel96
    Commented Jul 8, 2014 at 6:12

3 Answers 3


Most of the time you should be fairly safe.

OS-X is based on BSD which, like Linux, is a variant of Unix, albeit one of the more different versions.

It does however have very similar kernel and OS calls, and is considered to be Posix compliant, which is the main thing needed for cross platform operation.

The biggest issue your going to face when it comes to Apple's variation on things are

  • CPU & Processor architecture.
  • Additions made to the OS kernel but not released back into the wild.

Taking each of these in turn:

CPU & Processor architecture

All apple machines manufactured since 2007 have Intel based CPU's in them, however older apple machines used a variety of different CPU types ranging from the Motorola 68000 right through to the IBM PowerPC.

Some Linux projects do have in-line assembly language in them, especially things that are designed to interface to the kernel at a very low level.

On a modern day Apple with an Intel, this is not really too much of an issue, but if your trying to compile for something with a non Intel CPU in, your going to have problems.

Thankfully however, because of Linux's philosophy and open-source nature, this kind of practice is frowned upon, and very rarely seen in regular applications and tools.

Also, where an application is known to have platform specific parts in, there is often a ./configure script to run that 'configures' the sources for the platform being built on, or there is some way of specifying what the build target should be.

Additions made to the OS kernel but not released back into the wild

Apple are well known for putting thier own spin on things, and while I'm not an Apple developer (so I can't say for 100% what is and is not added), I do know a lot of other developers who are.

Going on the various comments and things I've been told by others, there are a number of OS facilities that are only available in Apples variation of the Linux base OS, and in some cases, developers are encouraged to use these in place of regular calls.

This really however, should only affect the porting of applications going the other way, in so much that, the target platform is tied to being apple and not easily portable to other variants.

Bringing in external apps should not be much of an issue as long as the application uses only standard posix based API calls, and does not try to do anything special or clever, or make any assumptions about the environment in which it is running.

The area where your likely to have the most trouble, is in the GUI space. Beacuse the GUI is so closely tied to the windowing library, and the windowing library is where most of Apples 3rd party extensions lie, then IMHO if any type of application is going to present you with a whole heap of problems, it's going to be here.

Most of the generic Linux stuff is designed to run under either a Generic X server, or using a toolkit such as Gnome or Kde, both of which (Correct me if I'm wrong here) I'm let to believe are not available on OS-X.

  • MacPorts Fink and Homebrew all support KDE as well as Qt and Gnome.
    – Stevetech
    Commented Jul 7, 2014 at 20:07
  • 2
    BSD is NOT a variation on Linux! (See en.wikipedia.org/wiki/Berkeley_Software_Distribution). BSD is a descendent of Unix while Linux is a Unix clone. (This answer is otherwise reasonable, but that sentence is just flat out wrong.)
    – user53141
    Commented Jul 7, 2014 at 20:22
  • @StevenBurnap - while I agree that your answer was once correct (BSD's full heritage does indeed stem from Unix) you will find that over the years since, BSD has gradually taken more and more into it's kernel that has come from the main-stream Linux distributions. There is also a comment in the book 'Rebel Code' by Glyn Moody from the original creators of BSD to the effect that "Some day, they would like to see BSD having more in common with Linux than it's Unix ancestry" - I think in this case, we both need to agree that there is an element of truth in both answers.
    – shawty
    Commented Jul 7, 2014 at 20:32
  • That said Linux or not, It's all about the level of Posix compliance as far as I'm concerned, and by that metric you could at least in theory if you so desired also bring the Windows NT kernel into the equation.
    – shawty
    Commented Jul 7, 2014 at 20:32
  • @Shawty I am don't see how that can possibly be true, given that BSD obviously can't take Linux code, which is GPL'd, and release it under a BSD license. While it is true that ideas from the Linux world have percolated back into BSD, in terms of basic design and code, BSD is a complete separate BSD, and in fact came before Linux. Therefore to call it a "variation on Linux" is just wrong. More accurate is to say that BSD and Linux are both Posix-compliant systems that support most of the same tools and compilers.
    – user53141
    Commented Jul 7, 2014 at 20:46

Instead of compiling from scratch have you investigated Homebrew MacPorts and Fink.All of these port unix tools to OSX with the heavy lifting already done for you. they also provide porting guides to enable you to port your own applications.

Each of these systems has its own adherents but to be honest they are much of a muchness, each has strengths and weaknesses and none is perfect.




There are other similar projects but I haven't tried those yet. i am currently using Macports but all seem to work just fine.


There are sometimes minor annoyances in porting code from Linux to OS X. For example, until Lion, OS X didn't provide a 'getline()' function, so you were forced to provide your own. Then when Apple added it in Lion, you had to have conditional compilation to include the home grown getline() when building on Snow Leopard, and leave it out when building on newer versions of OS X. It isn't rocket science but it is surely annoying. Aside from nits like that, the UNIX API provided by OS X is pretty compatible with Linux.

The biggest headache now is that Apple has moved on to Clang for it's compilers. Most Linux projects are still built with GNU GCC and a lot of code that will compile with the GNU GCC compilers will not compile using the Clang compilers. For example the Boost libraries seem to get broken and then patched with each new version of Clang or Boost. You may have to install a copy of the GNU GCC compilers from MacPorts or Homebrew to get stuff to compile.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.