Jump to content

Cross compilation

From Rosetta Code
Revision as of 22:46, 26 August 2022 by Thundergnat (talk | contribs) (syntax highlighting fixup automation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Cross compilation is a draft programming task. It is not yet considered ready to be promoted as a complete task, for reasons that should be found in its talk page.

Explain the process of creating, for example, a Linux executable binary on a Windows machine, and vice versa.
Include details of any and all compilation and runtime options for incorporating platform-specific elements.
Use the header ===baked in=== if the standard distribution contains everything needed, or ===third party=== if it depends on another toolchain such as GCC and additional setup/installation for that.
If your language cannot create executable files or is not cross-platform it should be omitted from this task.


FreeBASIC

third party

The FreeBASIC compiler supports all compilation targets. You only need to install one fbc per host system, and it can be used to compile both native and non-native programs.

  • default: compile for native system
  • The -target and -arch compiler options allow cross-compilation


Requirements for cross compilation:

The official FB release packages include a cross-compilable fbc, but fbc alone is not enough.

1. In addition to fbc, FreeBASIC consists of the FB runtime library (rtlib/libfb) and the FB graphics library (gfxlib2/libfbgfx). Additionally, FreeBASIC uses libraries from the MinGW, DJGPP, or Linux GCC toolchains. All these libraries are precompiled for a certain purpose.

2. FreeBASIC uses the assembler and linker (and sometimes even more tools) from the GNU binutils project to create binary files.

To keep the official FB release packages small, they only include the necessary libraries and tools for native development, but not cross-compiling.

Pascal

Free Pascal

many examples for crosscompiling to different targets. Cross_compiling Free Pascal

Phix

baked in

A simple format directive in the source allows for easy cross-compilation to any other supported system, for instance the Linux binaries of Phix are always compiled on Windows by throwing the following at "p -c -norun p32.exu" (with a similar p64.exu for 64bit, and formats PE32 and PE64 for the reverse trick):

format ELF32
include p.exw

The platform() and machine_bits() builtins can be explictly used as runtime tests to vary code by platform. The compiler tries hard to avoid emitting unnecessary binary, which is likely to be more successful when those routines are used as plainly as possible, without any and/or parts to the conditional. Likewise #ilASM{} aka inline assembly can contain guards such as [32] to emit (only) the relevant code for different target architectures, see Conditional_structures#ilASM and Pragmatic_directives#Phix for more.

The requires() routine can help ensure time is not needlessly wasted trying to get things to work on platform(s) where it currently simply does not.

Lastly, pwa/p2js can be used to transpile Phix code to Javascript for running in a web browser, with the compiler directive "with javascript_semantics" explicitly stating that is possible, and the "without" variant explicitly blocking it, with similar implications as requires(). The former also triggers runtime errors on desktop/Phix should incompatible operations be attempted, most notably use of copy-on-write semantics, and hence effectively/conversely Javascript's pass-by-sharing: addressing any such problem statements on desktop/Phix implicitly also ensures they will work in a browser. The transpiler(/syntax colouring) also populates rosettacode with the otherwise hidden tags (phixonline) when javascript compatible and (notonline) when not, the results of searching for which can be seen here and here respectively.

Wren

third party

Wren is basically a scripting language which lives inside a host application in the form of a virtual machine (VM). The host application communicates with the VM via the embedding API which (like the VM itself) is written in C99.

Host applications don't have to be written in C99 itself and bindings exist for several other languages including C++, Rust and Go. If a language exposes a C FFI, one can probably write a binding for it.

The VM is very small compared to, say, those of the Java or .NET family languages. Although it is typically built as a shared or static library which the host can link to, its small size means that it's a practical proposition to incorporate its source code directly in a host application written in C/C++ which can then be built directly by including the wren.h/wren.hpp header file.

The VM compiles the Wren source code into an intermediate bytecode which it then interprets at runtime. The compilation process is just 'single pass' which imposes some limitations on the Wren language but is so fast that the compile and runtime stages are virtually indistinguishable to the user.

Wren has a small standard library whose only dependency is the C99 standard library.

Athough it is possible to run Wren applications from the command line using Wren-cli (the main focus for RC tasks), technically the latter is just a host application for the Wren VM which uses the cross-platform C library, libuv, to implement IO functionality and supplements the Wren standard library accordingly.

Pre-built Wren-cli executables exist and are freely available for 64-bit Linux, MacOS and Windows. However, as libuv runs on many more platforms than these and virtually all platforms have a C99 (or C++98) compiler available, it should be technically possible to build a version of Wren-cli for any such platform.

To build a Wren-cli (or any other C/C++ host) executable which runs on a different platform from the development platform then one needs, of course, to use a C99 compatible cross-compiler such as the ubiquitous GCC which can be set up to do this provided binutils is available for the target platform. For some platforms (such as embedded systems) it may be necessary to use the newlib subset of the standard C library.

Finally, it is worth mentioning that a Wren to Javascript transpiler (via emscripten) exists which enables Wren applications to be run in a browser though this does have a dependency on node.js and various other stuff.

Cookies help us deliver our services. By using our services, you agree to our use of cookies.