972
edits
[unchecked revision] | [unchecked revision] |
m (Add link to the notes on all my ports) |
m (Bot: Replace deprecated source tag with syntaxhighlight) |
||
(5 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 134:
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]]
|