The previous package was broken (would often segfault, prevented
building Haiku cross-tools under x86_64), so update to the latest
version in HaikuPorts.
Signed-off-by: Alex Smith <alex@alex-smith.me.uk>
* I rebuilt all packages that depend directly on python: I hope I
didn't miss anything.
* SVN upgraded to 1.8.10 because I couldn't get 1.6.18 to build. This
required uodating expat, apr and apr_util, and adding serf which
replaces neon for SVN http support.
* Everything seems to be running fine so far.
* With HAIKU_NO_DOWNLOADS=1, the check against existing package files
in the download folder should only be done in the phase that is
adding packages to be put onto the resulting target image, not in the
phase that is adding the bootstrap packages (as here those packages
will be *built*, not downloaded).
Let the platform mmu_map_physical_memory the initrd region, and
reserve it before calling mmu_init. This removes another hardcoded
address, since e.g. U-Boot gets the address from the uImage file.
Many bugfixes, most importantly a bug was fixed which makes network
downloads go much faster (without waiting for you to wave the mouse over
the window).
Now that the fake packages are in place, it is much easier to build the
MMC image for ARM without the need for a bootstrap build.
This image still does not manage to access the tarfs and load the kernel
modules, but it gets to KDL, at least.
Needed for the test_app_server.
The logic here may need some improvements, but I'm not sure how to find
the right library name in all cases. I fixed at least the x86_gcc2 case
here.
- Revert the change to BuildFeature since the latest version of the zlib
sources package indeed uses the correct "sources" directory.
- Make the fake zlib package for ARM use the same revision number as the
current zlib version (4) so it can use the current version of the source
package instead of some older one.
This fixes the non-bootstrap ARM build.
I'm not sure this is the right fix, the zlib package seems to come with a
"source" (not "sources") folder on both ARM and x86_gcc2 but then I
don't understand how this worked for the x86_gcc2 build before.
The packages are the bootstrap ones, modified with the "unbootstrap"
script. Not recommended for real use, but this should make playing with
the ARM build a bit simpler.
The libsolv package somehow got lost in the process when I converted
those. Anyone with a copy of the libsolv_bootstrap packages in their
arm generated folder is welcome to "unbootstrap" and upload it.
