972
edits
Cross-Porting Software: Difference between revisions
m
Bot: Replace deprecated source tag with syntaxhighlight
| [unchecked revision] | [unchecked revision] |
m (Used wrong word) |
m (Bot: Replace deprecated source tag with syntaxhighlight) |
||
| (7 intermediate revisions by 3 users not shown) | |||
Line 39:
You extract the source code somewhere appropriate:
<
# Use --extract --file if you have a hard time surviving xkcd 1168.
tar -xf libfoo-4.2.tar.xz
</syntaxhighlight>
== pkg-config ==
Line 48:
Libraries increasingly provide pkg-config files that describe where the headers are installed and how to link against the library (and private library dependencies if statically linked). Working with pkg-config is preferable to fighting it (see below on packages rolling their own foo-config program) and it nicely supports system roots and is cross-compile aware. It's possible to compile a custom cross-pkg-config, or you can simply wrap your system one. Make a <tt>x86_64-myos-pkg-config</tt> executable shell script and put it somewhere in your path for the duration of the cross-compilation:
<
#!/bin/sh
# Fill these in appropriately:
Line 59:
# record that only static libraries were built.
exec pkg-config --static "$@"
</syntaxhighlight>
You then set <tt>PKG_CONFIG=x86_64-myos-pkg-config</tt> to packages use your custom pkg-config instead, and <tt>PKG_CONFIG_FOR_BUILD=pkg-config</tt> so packages that wish to compile local programs use the system pkg-config.
Line 71:
Secondly, you cross-build the package in this manner:
<
# Potentially unset CC and such here (see configure --help) to prevent local
# tools from being mistakenly used as cross-tools. Alternatively, set them to
Line 80:
make
make DESTDIR=$SYSROOT install
</syntaxhighlight>
This will cross-compile the software and install it under <tt>/usr</tt> on your system, inside your system root as the temporary installation location. Note how many packages remember <tt>--prefix</tt> and use it at runtime to locate their data files. You must not do <tt>--prefix=$SYSROOT/usr</tt> as that means libfoo would look files in <tt>/home/myuser/myos/sysroot/usr/share/libfoo</tt> while running on your operating system instead of <tt>/usr/share/libfoo</tt>. The <tt>DESTDIR</tt> acts as a second prefix for the purpose of installation, it's not revealed to the package before the install step, so it won't mistakenly remember it.
Line 130:
=== Gnulib ===
The GNU portability layer takes the form of a collection of files that everyone copies into their packages and then neglect to update often. These files are often deeply integrated into the package (i.e. hard to disable properly). The principle of replacing standard library functions if broken or missing is not too terribly bad - but Gnulib mixes it with a huge paranoia that the host system is terribly broken and assumes the very worst when cross-compiling. The result is that when you cross-compile these ports, huge amounts of compatibility code gets compiled in, and much of this compatibility code does not even work on unknown platforms. Of particular fun is code that needs to integrate deeply into stdio internals or when it replaces your printf. The result is that as you port packages, you often find yourself fixing the same gnulib code over and over (each time subtly different depending on when it was forked). When you improve your stdio implementation to be more standards-compliant, you find yourself needing to fix all those gnulib stdio-internals-aware files all over again, because some silly internal changed.
The solution is to scream in horror at how troublesome and unnecessary this scheme is as obviously you are capable of implementing a correct operating system. This racketeering scheme has <tt>#error</tt> statements that tell you to upstream preprocessor conditionals for your operating system, so they can relish in even more complexity that didn't need to exist in the first place.
[[User:sortie|Sortie]] has developed a [https://
=== Custom Configure Script ===
Line 150:
=== Exotic problems ===
As you start porting packages that rarely get ported or cross-compiled, you'll likely start finding some seriously
== Upstreaming Local Patches ==
Line 160:
It is probable that other community members have already ported a particular package. Their patches likely contain insight into how troublesome it is to do a port and what needs to be done. You can often find a collection of all their local patches in a central location.
* [[User:sortie|Sortie]] has a [https://
[[Category:Porting]]
| |||