Preface: my experience cross-compiling code is minimal, and I'm mostly coming at this from a golang background
I can cross-compile golang like so GOOS=<OS> GOARCH=<architecture> go build <source-file>
Where OS could be something like "linux" or "windows".
Why do I not need to specify which version of linux or windows (or whatever else)? Surely e.g. linux has changed over the years and I should need to specify a version if it depends on it.
I guess another way to phrase this question is, if I compile some code on my linux machine, would that run on all older version of linux? Surely not
A related question: I suppose OS here means OS in the sense of the kernel, not OS in the wider sense it is sometimes used to mean the whole GNU+linux system etc.
From the Go Wiki, the minimum supported Linux Kernel (GOARCH amd64 or 386) is:
2.6.23 or later
so basically any Linux distribution from late 2007 onwards.
Other Linux architectures (arm*, mips*, s390x) supported kernel versions can be found here.
Related
I want to see if its possible to determine the OS just by using assembly
the only related question i found was this :
What are techniques for determining running OS in assembly language at runtime?
but it doesn't really answer it. they are saying there is likely no way to do it but i doubt it, there has to a be way considering how vast the x86 architecture is (like looking at special register values, using some barely known x86 instructions and so on)
basically lets say you can write an assembly code, but don't know in advance which operating system it is going to get executed on (an application in that OS will jump to this blob of binary code)
now you need to detect whether its a Windows operating system or Linux, just in assembly (x86), how will you do it? the trick is to do it in a way that reduces the possibility of crashing as much as possible.
(Please don't ask why wouldn't you know the OS your code is executing on, its not part of the question, just assume you are in a situation that you just don't know)
I'm investigating options to create portable static Linux binaries from Fortran code (in the sense that the binaries should be able to run on both any new and resonably old Linux distros). If I understand correctly (extrapolating from C) the main issue for portability is that glibc is forwards but not backwards compatible (that is static binaries created on old distros will work on newer but not vice versa). This at least seems to work in my so far limited tests (with one caveat that use of Scratch files causes segfaults running on newer distros in some cases).
It seems at least in C that one can avoid compiling on old distros by adding legacy glibc headers, as described in
https://github.com/wheybags/glibc_version_header
This specific method does not work on Fortran code and compilers, but I would like to know if anyone knows of a similar approach (or more specifically what might be needed to create portable Fortran binaries, is an old glibc enough or must one also use old libfortran etc.)?
I suggest to use the manylinux docker images as a starting point.
In short: manylinux is a "platform definition" to distribute binary wheels (Python packages that may contain compiled code) that run on most current linux systems. The need for manylinux and its definition can be found as Python Enhancement Proposal 513
Their images are based on CentOS 5 and include all the basic development tools, including gfortran. The process for you would be (I did not test and it may require minor adjustments):
Run the docker image from https://github.com/pypa/manylinux
Compile your code with the flag -static-libgfortran
The possible tweak is in the situation that they don't ship the static version of libgfortran in which case you could add it here.
The resulting code should run on most currently-used linux systems.
I have been looking for a linux distribution that is not for embedded systems and does not use many of the GNU utilities found in many popular distributions. I want to develop a (pet project) linux distribution that uses musl-libc, bsd userland, and Plan 9 from user space. Before I start and possibly waste time doing the impossible, is it feasible/practical to use the BSD userland as a replacement for GNU coreutils? If not, what is an alternative?
Your goal appears to be much close to stali project (the only difference is the BSD userland requirement).
http://sta.li/
I don't know much about the stage of this project, but you can get some help in the project mailing-list.
As far as I know, the BSD tools uses a lot of direct syscalls and little usage of the POSIX API. I don't believe that bsd guys had written code using a lot of #ifdefs to get fully compliant programs (but I can be wrong)...
The suckless site ported the plan9 userland to unix (based on plan9port too), it's called 9base (and is available on archlinux repo to install).
I think you'll have the same problem I had in the past trying to assembly a similar distro: Too much effort to get rid of GNU... The base system is easy, but for something useful you'll need a C compiler and then you're out of good alternatives. GCC is gnu and have dozens of gnu dependencies and the sane freebsd gcc port never will work on linux for obvious reasons.
My current try is help finish the ken-c (or 9-cc) port for linux.
I recently came across multiarch in linux when deploying 32 & 64bit libraries.
Out of curiosity, why was /lib64 abandoned in favour of e.g. /lib/x86_64-linux-gnu
It seems overly complex but there must be a reason for that.
The long version can be found at http://wiki.debian.org/Multiarch , in particular http://wiki.debian.org/Multiarch/TheCaseForMultiarch .
The short version is that using triplets is a more general solution that allows things like multiple ABI's (such as x86 and x32, as Basile mentioned in a comment), emulators, cross-compilers and such without having to resort to various tricks.
Whether non-Debian based distros such as Fedora or OpenSUSE will adopt this remains to be seen; so far they don't seem that interested.
I would like to generalize a build system to compile on several (somewhat similar) platforms. What is a good method for determining the type of host that the shell script or Makefile is running on. I would like to distinguish between mac and linux, but also different specific distributions of linux (e.g. RHEL, Ubuntu). Cygwin is not important for me, but if you include it in your response I am sure others will find it valuable.
The rationale may include using the host type to fetch and install the correct versions of binary packages when it is more convenient to do so than compile from source. In addition, some commercial software is binary-packaged for specific distros, so part of the motivation is to grab the right binary.
Thanks,
SetJmp
Autotools to the rescue. It has tons of macros that help you do this kind of stuff.
http://www.lrde.epita.fr/~adl/autotools.html
uname -a to distinguish major *nix variants
Not so sure what the best way to distinguish red hat from ubuntu would be - could look for package managing tools and query installed packages, eventually helping you narrow down different debian derivatives, etc. There's probably something more obvious and up front though.
linux variants generally store distro information in /etc/issue.
most kernels will put info in /proc/version
It's not completely straightforward. You can use uname to find out the general parameters but to differentiate between distributions is a harder task. Maybe you should consider using something like autoconf to generalise your build system?
Just in case you're using Qt, there's this really nice set of defines, Q_OS_*, that guide you to the Operating System you're compiling on:
Q_OS_AIX
Q_OS_BSD4
Q_OS_BSDI
Q_OS_CYGWIN
Q_OS_DARWIN
Q_OS_DGUX
Q_OS_DYNIX
Q_OS_FREEBSD
Q_OS_HPUX
Q_OS_HURD
Q_OS_IRIX
Q_OS_LINUX
Q_OS_LYNX
Q_OS_MAC
Q_OS_MSDOS
Q_OS_NETBSD
Q_OS_OS2
Q_OS_OPENBSD
Q_OS_OS2EMX
Q_OS_OSF
...
They are defined in QtGlobal. There are even defines that help you figure out the compiler used Q_CC_* or the target Windowing System Q_WS_*.
But if you're not using Qt and want to go for a generic method, you most likely have to fall back to the Autotools package or CMake.
Determining Linux distributions is pretty tricky, but not hard. You first have to figure out what distributions you care about and then make all kinds of distribution specific file/configuration checks like in this example for the ones you've chosen, since you can't really support all of the myriad of Linux distros available out the. :-)
As for the Mac side i'll let the Mac experts answer, but it shouldn't be that hard, since at least the diversity issue is out of the question.