* To avoid problems caused by the varying python versions used by the
different architectures, switch those packages from 'any' to explicit
architecture.
This also adds the libtool_cross_generic package to ARM bootstrap,
which seems to be required for building ncurses successfully. I did
not have the time to verify that this is the case for x86_64 too, so
I'm not yet adding it to there (yet).
Since hrev47198 we have ELF-based TLS support in Haiku. When building
gcc with haikuporter, this is detected by the configure script, but when
cross compiling gcc we need to manually enable it, as no runtime check
can be performed to detect the feature.
This should fix#10938 by avoiding the mix of TLS and non-TLS libstdc++.
* Cleanup the SD card image building to allow jam -q @bootstrap-mmc to
work.
There are a few remaining tricks before you can safely build an image:
* This uses a non-POSIX du option, and is only tested with Linux du
only (Linux is the only supported system to run bootstrap builds,
anyway)
* The Python recipe in haikuports.cross is known to not build on
Debian/Ubuntu, but work fine on OpenSuse. There is a patch available in
haikuports bugtracker to allow the reverse.
* You need to populate the haikuports repo package list with some
packages (which don't exist yet) to make the build system happy. But our
git hook to generate the repositories is preventnig me to share this
hack.
Once built, the image currently crashes early in the kernel execution.
On to debug that!
* That change did not make any sense, as the floppy-boot images
can't be built in debug mode anyway (the result is much too large).
This reverts commit 911821275a.
libalm.so is used by Stack & Tile as well as for the constraint-based
layout BALMLayout. This also adds libalm.so to the development package;
links it to /boot/system/development/lib.
* data files are still in the source tree.
* gutenprint headers contain a image.h header file which collides
with ours. This is solved by forcing include search first on
os/kernel directory.
* This solves the issue where libreadline wasn't actually linked to libncurses
* x86_64 update will follow later, as the build maxed out my x86_64 build VM
