Compiling freebsd on linux

Running FreeBSD binaries on Linux

You cannot run binaries built for FreeBSD on Linux (see this question). They basically are different operating systems, sharing only a small subset of APIs (POSIX compatibility).

However, if you have the source code, you can build binaries for Linux on FreeBSD; the term is «cross-compiling». For example, programs for Windows are often compiled on a Linux system.

In theory, you could have an operating system run binaries made for other operating systems. In practice it takes work, and it doesn’t happen a lot because people don’t want to do the work for it.

There are a few things that can get in the way:

• Different Chips
• Different system calls
• Different library calls
• Files/paths are different.

So, lets say you want to run an Intel FreeBSD binary on an Intel Linux machine. The chip would be the same, no emulation needed. But the syscall interface is different. Someone would have to write code for the Linux kernel to realize that when you run a FreeBSD binary, to use a different syscall table. This made a bit easier since they’re both UNIX, a lot of the code can be the same.

But then you’d need the libraries. These could be in theory copied from a FreeBSD distribution, and the dynamic loader would then know this special place for FreeBSD libraries. If there were any config file paths, or hard coded output paths, this would have to be dealt with as well.

So, its doable, but it takes work. A lot of work. As such, the work is done usually only for a unpopular (or too new) OS to run binaries for a more popular or established OS.

Initially, Microsoft NT was able to run OS/2 command line apps, and had some theoretical (half-assed) ability to run POSIX apps. This ability has been dropped as OS/2 became irrelevant, and people liked NT for NT, not as anything that could run POSIX. I’m not qualified enough to say whether Windows 7 running Windows 95 apps is considered running from another OS, or just runs some ancient code melded into Win7.

Mac OSX could run MacOS 7/8 binaries if they were coded for something called Carbon (a set of compatibility libraries). This helped in the migration to MacOSX. They needed emulation for the PowerPC chip as well.

Since Linux is more common than FreeBSD, there really isn’t a need for a lot of people to emulate FreeBSD on Linux. It would be rare for an app on FreeBSD to not be available on Linux. So no one has done that work. But, there is capability for FreeBSD to run Linux binaries. Since Linux is a moving target, the emulation needs to be updated when the Linux kernel changes a lot, or it needs new libraries.

Источник

Articles

How to make a cross compiler (gcc) for freebsd under linux. A small tutorial.

Why a C/C++ Cross Compiler is useful

I manage a Hudson CI Server that runs on a linux system where I work, and one of our projects is written in plain C code that should be able to run on linux and also freebsd 7. Up to now we were using a freebsd (hudson) slave node in order to build the freebsd binaries. So I decided to get rid of it and try to build the code in the main hudson server, for both linux and freebsd. The solution: to build a full cross toolchain that can generate freebsd 7 binaries in a linux box.

You can find the source for this article here.

What is a Toolchain and why it’s needed to build software

Generically speaking, a toolchain is a set of tools (other software) that is run to generate other software, in a certain specific sequence. In this case, we are talking about a C/C++ preprocessor, a C/C++ compiler, an assembler, a linker, etc.

One operating system: Multiple toolchains

We are going to use our current toolchain (installed in a linux box) to generate a new toolchain that builds freebsd 7 binaries for either 32 or 64 bits cpu’s. This new toolchain will be installed in parallel to our current toolchain, so we can still generate binaries for linux also. This is a halfway to the infamous canadian cross.

The canadian cross: The foundation stone of cross compiling

• The native compiler (1) of a machine (A) is used to generate the native GCC (2) for machine A.
• The compiler 2, is used to generate the GCC cross compiler (3) that runs on A, but generates binaries for a machine B.
• The compiler 3 is used in B to generate a GCC cross compiler (4) that can generate binaries for machine C.

In our particular case, we already have compilers 1 and 2 because linux systems will mostly have a preshipped version of GCC fully functional. In order to simplify things a little, we’re gonna stop at making the compiler 3, that is the cross compiler from machine A (the linux box) to the machine B (the freebsd box).

About GNU targets: Choosing what to build and how

• Host target, which describes where the software is being built (hardware architecture and operating system).
• Build target, which is the hardware architecture and operating system where the executable is intended to be run.

Requirements for cross compiling in Linux for FreeBSD

• The linux box, of course, with a full and working GNU toolchain (or any other propietary toolchain) to build the cross toolchain that will generate the freebsd binaries.
• FreeBSD 7 include files (the whole /usr/include)
• FreeBSD 7 stubs: (/usr/lib/crt1.o, /usr/lib/crti.o, /usr/lib/crtn.o)
• Freebsd 7 libc: (/usr/lib/libc.a, /usr/lib/libc.so, /usr/lib/libm.a, /usr/lib/libm.so)

GNU Software needed

If you decide to use GCC >= 4.1.x (like I did), you will also need:

I’m going to use /usr/cross-freebsd as the prefix for the installation.

Step 1: Build GNU binutils

GNU Binutils has some low level utilities that can manipulate executables. You can get it directly from GNU

Uncompress the distribution, configure the software, build and install:

Step 2: Install freebsd specific files

Remember that I told you to go get some files from a freebsd distribution? It’s time to use them.

Following the GNU toolchain convention, create the following directories:

Deploy the contents of /usr/include in /usr/cross-freebsd/x86_64-pc-freebsd7/include
The files you got from /usr/lib in /usr/cross-freebsd/x86_64-pc-freebsd7/lib.

Step 3: Build the GNU tools needed by GCC

Skip this if you’re using a gcc < 4.1.

GMP

Uncompress the distribution, configure the software, build and install:

MPFR

Uncompress the distribution, configure the software, build and install:

MPC

Uncompress the distribution, configure the software, build and install:

Step 4: Build the cross compiler

NOTE: GCC requires to be built in a directory that is not the source dir, that’s why we are creating an objdir. See below:

Uncompress the distribution, configure the software, build and install:

Changing the LD_LIBRARY_PATH is necessary so the gcc build wont fail when trying to use mpc and mpfr.

Step 5: Test the installation with a simple program

Write a simple «hello world» code in C to test the native and cross compilers:

Step 6: Test the installation with a gnu software

We will now try to build a full gnu program with our brand new cross compiler. i.e: libxml2

Get and unpack libxml2. Enter the source directory:

Now, if you copy (for instance.. ) xmllint to a freebsd box, you should be able to run it 😉 You’re all set.

Cross compiler aftermath

As you can see there is some complexity in effectively building a cross compiler, however it IS a pretty straightforward process when you know the steps involved. It’s also very easy to break things when you start playing with different options for binutils and gcc. Anyway, following these steps will (generically speaking) help you setup a cross compiler for whatever target you need (the details may vary, but the steps should be almost the same).
You may also try to compile and install other stuff, like m4, autoconf, autoheader, libtool, libiconv, libxml2, etc to a directory and the move the whole directory to the target box, it should work like a charm 😉

If you liked this or other articles (and feel generous), you can make a donation:

Related Articles

• Validate client SSL certificates in your application with HaProxy
• Setup multiple backends in HaProxy with ACL, one SSL certificate, and SNI
• Virtual webcam as phone camera in Android Emulator in Linux
• Android Emulator in Linux with VNC and without GPU support
• Solution for «ERROR: 32-bit Linux Android emulator binaries are DEPRECATED»
• Running the Android Emulator as System Services with Daemontools
• Convert MAC EOL to Unix
• How to compile NGINX with external OpenSSL libraries and custom linker options
• WebRTC with Asterisk and Amazon AWS
• Using ACL by IP Address in HaProxy TCP Mode
• Automatized daily mysql backups to S3 buckets
• Compiling and Installing WebRTC2SIP
• Installing DaemonTools in Amazon Linux (or CentOS like OS)
• Starting WebRTC2SIP as a service without screen or console
• How to setup nginx to work with FastCGI and PHP 5.2 and PHP 5.3
• Configuring postfix to forward all email to a smtp gateway
• Different relays in postfix based on regular expressions

Источник

Building on non-FreeBSD hosts

Until recently, FreeBSD could only be built on a FreeBSD host. However, most CI systems do not include FreeBSD build slaves by default. If we allow FreeBSD to be compiled on a non-FreeBSD host (current target is Linux and macOS) it is easier to use these CI systems. Furthermore, it allows developers who do not have a FreeBSD system at work to use that to work on FreeBSD.

Instructions for building on Linux/macOS

Since Linux and macOS don’t include a version of bmake by default, building should be done using the script tools/build/make.py which will bootstrap bmake before attempting to build. Additionally it will set the required XCC,XLD etc variables that are needed to build with an ExternalToolchain if not opting to use the in-tree LLVM. If you have a recent version of bmake installed using homebrew or another package manager you can also set the required variables manually (the easiest way to obtain them is by running tools/build/make.py --debug). The script also passes any additional command arguments, like -j X or targets, to bmake.

MAKEOBJDIRPREFIX=. tools/build/make.py buildworld TARGET=foo TARGET_ARCH=bar .

Prerequisites on macOS

tools/build/make.py should work out-of-the box on macOS with clang and libarchive installed via homebrew:

brew install clang libarchive

Prerequisites on Linux

You will need a recent version of clang (ideally 10.0) and the libarchive + libbz2 headers (libarchive-dev and libbz2-dev packages)

Using the in-tree toolchain

Instead of installing clang via your system’s package manager, you can pass --bootstrap-toolchain to tools/build/make.py to build the in-tree LLVM and use it for the cross-build. This more closely matches building natively on FreeBSD (where the in-tree LLVM is used unless it is the same version as the existing system build of the in-tree LLVM), but will be slower than using a pre-built LLVM for your OS.

History

Why crossbuilding from non-FreeBSD didn’t work

• Some build tools depended on host headers being compatible with target headers (e.g. localedef). This required some refactoring of the xlocale headers to fix properly.
• The version of clang contained in the FreeBSD source tree could not be bootstrapped with the makefiles from base since the config headers depended on FreeBSD
  • Could have built the in-tree clang using CMake+ninja (which should also be much faster than the current Makefile solution), but that would have been a lot of effort
  • Initial solution was to just use upstream clang as an external toolchain until the config headers and build system were patched to support Linux and macOS
    • However, some features such as ifunc-noplt are not in upstream clang
    • This can cause strange build errors if that binary was not bootstrapped and an incompatible versions is executed
    • Can also happen when building on FreeBSD (e.g. running dtc from an old FreeBSD version)
    • Building with a clean $PATH D16815 fixes this problem since it requires all bootstrap tools to be listed explicitly

    Источник