I often have use for software that requires compilation, on machines that don't have developer tools installed. Today I found something that I thought would simplify my life. Brew-pkg allows you to create installer packages of things that you already have installed on your system. I took it for a test spin by creating a tmux installer package. Before I knew it I had a an installer. What's more, it worked on a handful of test computers. So I went ahead and distributed the packaged to a number of other computers including some Mac OS 10.6 machines. Sadly, on these machines, tmux just reports Illegal instruction and then stops.
So, my question is twofold.
Is there something I don't understand about how binaries work that explains this behavior?
How can I create pkg installers that install and work on various Mac OS versions?
Confusedly,
Cory
Related
I would like to try scidb as a replacement for hdf5. I would like to test it on my Debian laptop (no clusters) to give it a try.
Is this possible? Might be that Debian (as opposed to Ubuntu) is not supported?
I had no luck with the installation instructions. The deployment script tells that my OS is not supported. The scidb userguide says about some pre-built packages (for Ubuntu, at least). But there is no hint on how to obtain them.
SciDB is limited to RedHat / CentOS, and to Ubuntu as of the 14.9 release. Folk who want to run it on other distros generally compile from code.
Information about how to obtain the sources (as well as current documentation and community discussion) can be found on the forums here ... http://www.scidb.org/forum/. You'll need to register as a forum user.
Specifically, have a look at http://www.scidb.org/forum/viewtopic.php?f=16&t=364. There's a list of releases and links to code bundles there.
I installed SciDB several times using several ways (building from sources and installing from packages, installing the cluster version and the dev version).
Installation from packages
First, if you choose to install from packages (the easiest and fastest way), SciDB is very very sensitive about your Linux version. For example, for the last version of SciDB (14.8), if you choose to install on a Ubuntu, it has to be a Ubuntu 12.04 (and not a 14.04, a common mistake) 64 bits (meaning you have to install the AMD64 version even if you have an Intel processor). It won't work if you have a different version.
If you have an Ubuntu 12.04 AMD64, Paradigm4 provides a deployment script and a documentation with very simple steps:
https://github.com/Paradigm4/deployment
Installation from sources
It's not so difficult but it can be painful and time consuming. I did it because we had to compile a custom plugin for SciDB. You have two types of installation: dev install (in SciDB user directory) and cluster install (in /opt/ directory).
You have to be registered on their forum to have the link to the source code. They provide a specific documentation to build from source.
Good luck.
Several months ago I have dealt with porting SciDB 14.12 to an unsupported Linux - Fedora 19. If your OS is not supported, it will neither be supported if you try to install from the sources. You have to start from the sources, but then you have to adapt the deployment and installation scripts. The sources can be downloaded from SciDB forum.
Namely, add a new platform to deployment/common/os_detect.sh. Then, there are multiple platform specific deployment scripts, such as deployment/common/prepare_toolchain.sh, deployment/common/prepare_coordinator.sh and deployment/common/prepare_chroot.sh. You need to make sure those prepare the environment as they would on the supported OS'. I used Red Hat 6 and CentOS 6 as a reference, as those are both more similar to Fedora. Since your OS is Debian, you can first try falling back to Ubuntu deployment (in os_detect.sh).
Another problem you may encounter are the 3rd party tools, specially Boost. In my case, I had to build it manually from sources.
Sometimes when porting and debugging it is not convenient to run the scripts with deploy.sh, but it's better to run the deployment scripts directly on the target machine (e.g. coordinator).
Probably the best way to install and to start with SciDB is to download a standard image. With this image you only have to import the virtual machine with a software to virtualize. Moreover there are some characteristics of this virtual machine that are great to develop your first applications.
The main advantage, is that you have an API to SciDB queries and another to R. Then you can explore all options and to test SciDB.
This is the version that I downloaded few months ago: http://www.paradigm4.com/forum/viewtopic.php?f=14&t=1329&sid=606f614e401900cfa750375ba56de656
Nevertheless, there is a problem, the community is too poor. There are little people developing with SciDB.
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
I have the feeling that this would involve major nitty-gritty-details-stuff, nevertheless I'd like to give it a try:
Actual question
What do I need to do to set up an cross-compiler environment that allows me to build package binaries for platforms other than MS Windows (I guess at the moment this would only be Mac OS's tgz binaries) on MS Windows? The accepted answer in this post suggested that this is possible.
Background
I have quite a few mac users in my university's beginners R course that don't really know their way around the system specifics of Mac OS and therefore would be overextended with setting up the necessary development tools it takes to compile from source on Mac OS. Therefore, I'd like to offer them a tgz binary, but I need to compile on Windows as there's no apple hardware available to me.
I have a C# application that works great in Linux and Windows. Now I want to make an installation package for the Mac OS but I don't have anything running it in order to develop it / test it. The software is open source, so I don't want to put money into buying yet another laptop just to test it.
Is there a way to create some kind of installer / package for this C# application without actually needing to have a Mac? I even made a .deb package for Linux. Isn't it possible to somehow convert it?
It depends on how fancy you want to get with the installer. I'd start with something simple like building a package for Homebrew.
That's all command-line, though. If you think your Mac users would be unhappy installing an running from the command-line, you'll have to look into more sophisticated solutions. Mac GUI applications are traditionally built into .app bundles. Unfortunately for you, C# does not have lots of support for cross-compiling to the Mac. It's possible, but it's going to take a lot of trial and error, which will be way more frustrating without a test machine to see if you're doing it right.
You might try CPack (part of CMake). CMake doesn't really do C# (otherwise it'd be perfect for you), but you may be able to point CPack at the completed binaries and get it to bundle them up for the Mac for you. You could also use CMake/CPack to build a dummy Mac application and then you'd be able to swap out all the pieces for your own binaries.
I am sort of switching to a Mac based development environment as the Mac line of laptops and workstations contains some very nice systems, albeit pricey. As an occasional Emacs developer, I want to build Emacs from the git/bazaar sources. Much to my surprise, the first time I attempted to do this using Xcode4, I discovered that the version of autoconf supplied with Xcode is less than that required by Emacs. So this raises the question: what approaches do those who develop Emacs daily using Mac hardware take in order to have the required libraries and headers available to build and run the Emacs development code on OS X? Left to my own devices, I will fetch and build the versions of components required by Emacs that are not satisfied by Xcode and put those into /usr/local/... but it does occur to me that other approaches, using fink for one example, might be less work and/or more satisfying, hence the question. This also applies to the add-on packages for graphics support (pdf, dvi, png, etc.) that are not supplied by Xcode.
The directions in the file nextstep/INSTALL is to issue the following commands:
./configure --with-ns
make install
The resulting "app" can be found in nextstep/Emacs.app.
However, there is an XCode project provided with Emacs, but I haven't got it to work.
I use the macports package 'emacs-app', which is just emacs configured --with-ns. They're currently at version 23.2.1
Even if you want to build emacs direct from GNU repos, using macports to get autotools should save you some time and energy. The autoconf package is at 2.68, and emacs configure.ac requires 2.65