The use of make
by itself is very common
in both proprietary and open source software.
Unfortunately, Makefiles are often not written with
cross-compilation in mind.
Thus, devtool add
often cannot do very
much to ensure that these Makefiles build correctly.
It is very common, for example, to explicitly call
gcc
instead of using the
CC
variable.
Usually, in a cross-compilation environment,
gcc
is the compiler for the build host
and the cross-compiler is named something similar to
arm-poky-linux-gnueabi-gcc
and might
require some arguments (e.g. to point to the associated sysroot
for the target machine).
When writing a recipe for Makefile-only software, keep the following in mind:
You probably need to patch the Makefile to use
variables instead of hardcoding tools within the
toolchain such as gcc
and
g++
.
The environment in which make
runs
is set up with various standard variables for
compilation (e.g. CC
,
CXX
, and so forth) in a similar
manner to the environment set up by the SDK's
environment setup script.
One easy way to see these variables is to run the
devtool build
command on the
recipe and then look in
oe-logs/run.do_compile
.
Towards the top of this file you will see a list of
environment variables that are being set.
You can take advantage of these variables within the
Makefile.
If the Makefile sets a default for a variable using "=",
that default overrides the value set in the environment,
which is usually not desirable.
In this situation, you can either patch the Makefile
so it sets the default using the "?=" operator, or
you can alternatively force the value on the
make
command line.
To force the value on the command line, add the
variable setting to
EXTRA_OEMAKE
or
PACKAGECONFIG_CONFARGS
within the recipe.
Here is an example using EXTRA_OEMAKE
:
EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
In the above example, single quotes are used around the variable settings as the values are likely to contain spaces because required default options are passed to the compiler.
Hardcoding paths inside Makefiles is often problematic in a cross-compilation environment. This is particularly true because those hardcoded paths often point to locations on the build host and thus will either be read-only or will introduce contamination into the cross-compilation by virtue of being specific to the build host rather than the target. Patching the Makefile to use prefix variables or other path variables is usually the way to handle this.
Sometimes a Makefile runs target-specific commands such
as ldconfig
.
For such cases, you might be able to simply apply
patches that remove these commands from the Makefile.