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.
* From now on, the gcc-specific system libraries (libgcc, libsupc++ and
libstdc++) are provided by separate packages built along with gcc:
- gcc_syslibs contains the shared libraries (libgcc_s.so, libsupc++.so and
libstdc++.so)
- gcc_syslibs_devel contains the static libraries and both c++ and gcc
headers
The shared libraries now make proper use of symbol versioning and there
are version-specific symlinks
* The buildsystem has been adjusted to no longer use the libraries and
headers from the cross-compiler, but use the ones provided by the
above-mentioned packages. The only exception is that the 32-bit libraries
required for the bootloader of the x86_64 architecture are still taken
from the cross-compiler.
* This stage builds the gcc packages to get the shared syslibs, which
only requires the Haiku glue code.
* Add separate declaration section for stage0 packages to
HaikuPortsCross repository files.
* For the bootstrap_stage0 platform, fall back to the gcc headers
provided by the cross-compiler.
* No longer apply somewhat crude mechanism for converting a package name
into a corresponding port name - haikuporter by now supports package
names directly.
This fixes a problem when trying to pass 'gcc_syslibs_devel' to
haikuporter, which only ever saw 'gcc_syslibs'.
* Drop unused variables from build system that refer to the system
libraries.
* Drop unused lists of libgcc objects.
* Drop no longer used variables from configuration script.
* Remove no longer needed building of kernel-libgcc and -libsupc++ from
build_cross_tools_gcc4, only the boot-specific (32-bit) libs are
built for a x86_64 target.
* Explicitly disable threads and TLS support when building the cross
compiler, as the only libraries that are used by Haiku's build system
is the 32-bit libgcc and libsupc++ for the bootloader on x86_64 (and
for that neither is wanted).
* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.
provided in the gcc_syslibs_devel build feature for building Haiku.
* Simplify declaration of c++ and gcc headers for the legacy compiler -
in the end we always use the ones living by our source tree anyway.
* Fix a couple of missing local declarations for jam variables, which
were necessary to avoid a build problem with strace. There are
probably more bugs like these hiding in our build system files, but
I'm saving the fix for those to the next commit.
* Add new gcc packages to the HaikuPorts (x86*-)repositories.
Parentheses in target names are considered by Jam to mean an archive
member. We have to explicitly use the M selector to keep that part.
Fixes#10378 (certain keymaps missing on image).
Stop-gap solution to make smpeg installable until the separate libstdc++
package is available. Then it will hopefully have a reliable "compat"
version we can depend on.
