I want to make a Ruby extension for a C (with C++ libraries) program that will run on a CentOS server, but it would be more convenient for me to work on a Mac (especially without having to reinstall all the 3rd party libraries).
Since they're both UNIX-based, would creating the library in OS X throw it off once I put it on CentOS, or should I just man up, install CentOS, and do it all there?
Thanks!
You don't even have 100% source compatibility between them, although you can easily stick to what will work on both.
There is no binary compatibility between Linux and OS X; even the basic object file formats differ (Linux uses ELF, OS X uses Mach-O).
Related
My coworker and I are both using Go 1.9 x64. I'm running Linux Mint 18.2 and he's running macOS Sierra 10.12.6. We ran the exact same script to cross compile a program for Windows x64 and out of curiosity we diffed the files to see how similar they would be. We expected to find a few build parameters or IDs to be different but it turns out there are a LOT of differences all throughout the files.
We made sure the two programs were built off the exact same code. The program really doesn't do anything too OS specific. It reads a JSON file and executes a series of web requests determined by that file. Nothing like executing shell commands or reading/writing the windows registry. No CGO, the only use of the os package is os.Exit(code) calls, nothing stands out as a culprit.
Even though the programs were built from two different host OSes, they were both built for the same target OS with the same version of the Go compiler and the same code files. Why are the output binaries so different?
I'm trying to decide what haskell installation is more appropriate for a Mac running El Capitan.
It seems there are at least two alternatives:
Install the haskell platform as indicated in https://www.haskell.org/platform/
Install the haskell platform as indicated in https://ghcformacosx.github.io/
What is the difference between the two distributions?
Will I be able to use Xcode as an Haskell IDE?
The main differences I see are:
Haskell for Mac OSX:
is relocatable
comes with stack pre-built
Haskell Platform:
installs in /usr/local/bin (requires root access)
comes with more pre-compiled libraries
comes with the programs happy and alex pre-built
Neither comes with explicit support for using Xcode as an IDE. Usually one uses Emacs or Atom or Vi to develop Haskell programs.
How do I install a current Frama-C release and its prerequisites on Macs?
I have a laptop running Mac OS X 10.6.8 and a desktop running Mac OS X 10.7.5
which I can install software on. I also have access to a lab of machines
running Mac OS X 10.8 which our technical support people will install stuff on
if I ask nicely.
I have a student who is interested in program analysis and needs something
that we have a fighting chance of understanding and adding to. I was already
aware of Frama-C, and a colleague at another university recommended it.
I had previously tried to install Frama-C and failed miserably. The colleague
commented that he'd had the same experience. Well, times change. So I visited
the Frama-C web site, was more impressed and keener to have it than ever, and
set about it.
The frama-c.com download page doesn't have links to any binaries for the
current (Flourine 3) release for any platform. The link to installation
instruction takes me to a page that says to download the auto-installer.
What auto-installer?
There are instructions for an old version of Mac OS X, but following them
didn't work; loading one set of prerequisites as instructed produced a
state where the next prerequisite (gtksourceview) would not install.
Of course I checked the older releases, and I see that there's a Nitrogen
version for Mac OS X Leopard, but "Please untar the archive as root in /"
asks me to perform the impossible. I don't have a root account and will
never be given one (the machines all belong to the university). It is
perfectly possible to install gcc and clang anywhere you like; why does
Frama-C want to be in /?
In addition to Pascal's answer, you can also have a look to opam, which is a source package manager for OCaml applications. It appears to run on MacOS X, and there are packages for Frama-C's Oxygen and Fluorine.
All Frama-C binary packages want to install in / (precisely, in /usr/local/Frama-C) because Frama-C uses GTK+ and various GTK+-related libraries that were never designed to run from anything other than a fixed location. They load configuration files and resources from paths that have been hard-coded at compile-time. GCC and Clang install anywhere because they don't rely on GTK+. Like them, the command-line version of Frama-C can be relocated through various environment variables listed here.
Note that to take advantage of a binary package, you would only need one symbolic link pointing from /usr/local/Frama-C to the place where you really extracted the files, if your administrator(s) can grant you that. Binary packages only work for one OS X version. For packages available from the official website, this version is usually 10.6 (Snow Leopard).
I have ceased making Frama-C binary packages for two reasons:
by removing features and support for hardware configurations in each of the last two OS X releases, Apple has fragmented the OS X landscape in a way I don't have the time to deal with. You mention 10.6, 10.7 and 10.8 in your question. I also have Macs running each of 10.6, 10.7 and 10.8. They are all incompatible (when trying to build a software package that includes a compiler).
I have much less time available now that I am participating in the creation of a start-up that offers Frama-C-based static analysis to interested industrial users.
This said, Frama-C the Open-Source advanced research prototype continues to be developed and maintained, and continues to be a great testbed to experiment in. You can install Frama-C without root access on a Mac in two ways apart from what you have already tried:
Install only the command-line version. Then the only dependency is a recent version of the OCaml compiler. Frama-C's configure will detect that you do not have the GTK libraries and will not try to use them. Installation should take 20 minutes at most for a recent OCaml + the latest Frama-C.
Install a recent Linux distribution in a virtual machine. Use that distribution's package manager to obtain all the GTK+ dependencies. If the distribution's OCaml package is recent enough, use that and then the lablgtk-2 package, otherwise, compile OCaml and then lablgtk-2 from source. Then compile Frama-C.
For Fluorine, the oldest supported OCaml version is 3.12.1.
with macports:
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
sudo port install opam
opam init
Y
eval `opam config env`
sudo port install gtksourceview2 lablgtk2 ocaml-ocamlgraph
opam install frama-c
Is it possible to develop cross-platform application on Windows and can also compile for Mac OS X from Windows? I have checked Qt but that requires one to compile from Mac using Xcode.
If this is your priority then one option would be Java as at least a jar file built on one platform can be run on another.
If however you're talking about C or C++...
If you are creating a small command line tool then you might be able to make this work with gcc and a cross compiler, but I think it would be a lot of work.
If however you are wanting to create a GUI application I would urge you to give up now. There are so many issues - you'd have to use Carbon or Cocoa APIs which you can't build for on any other platform, you'd have to link against frameworks which won't exist on your compilation host, you won't be able to easily generate .plist files. Qt won't help as you need to be able to build it, which relies on these same frameworks.
In short, there's no alternative to building on an actual mac.
Furthermore, when it comes to fixing bugs, you will absolutely have to do this on a mac (either physical or virtual).
From what I know , in general you do need a mac to make the executable , even for a simple ansi c program you need gcc for mac.
You can create MacPorts Portfile.(If your application is open source)
A MacPorts port is a set of specifications contained in a Portfile
that defines an application, its characteristics, and any files or
special instructions required to install it. This allows you to use a
single command to tell MacPorts to automatically download, compile,
and install applications and libraries.
Take a look at IMCROSS.
IMCROSS is a simple, scripted method of installing cross-compilers and
cross-compiled libraries on a Linux (or possibly other *nix) system,
so that you can develop programs targeted to run on Microsoft Windows
and Mac OS X at the same time and in the same environment as you
develop Linux versions of those programs.
You can certainly do this using Real Studio. It can create Mac OS X applications on Windows without any trouble.
It cross-compiles for Windows, OS X and Linux. And it does it from any platform. It also can create web apps.
Sounds like you should check it out.
Hi stackoverflow community!
I am about to start developing patches for FreeBSD Ports Collection (pkgng utility) using C programming language.
The problem is that I am using Mac OS X and I am really do not want to switch to another operating system. I have installed Freebsd 9.0 on Parallels Desktop VM. Xcode 4.1 seems to be rather nice development tool for C.
Is it possible to implement development for FreeBSD via Xcode 4.1? How to set up project environment for such form of development and compile source for FreeBSD?
I am also opened for any other suggestions concerning cross-platform development using MacOS X to develop patches for FreeBSD. Which is the best way to organize all necessary stuff?
Since you want to develop patches for pkgng, I would strongly suggest that you compile and test the code on FreeBSD, because it is the only system that uses the ports and packages system that pkgng interfaces with. So unless it can cross-compile for FreeBSD, using any OS X IDE is probably not a good idea.
I'm not familiar with Parallels, but there is probably a file-sharing mechanism that you can set up between OS X and the FreeBSD running in the VM. That way you can edit your files on OS X and use them under FreeBSD.
X Code is really nice, and I would lean toward using it but then doing regular builds on a system actually running FreeBSD. If you have source for everything you're using (except standard libraries whose interfaces match), there is no reason not to work on OS X with Xcode. You can build your own libraries if need be. One thing writing cross platform does (provided you regularly build on the other platform) is make your code more portable. It's easier to avoid using platform specific "extensions".