On GCC 7.3, it conflicts with our definition of 'fork'. The documentation
states that disabling builtins has no effect on versions where they
do not exist, so we don't need to check for GCC7 here.
* Actually locate the clang executable, and allow user overrides
* Properly preserve arguments in get_build_tool_path
* Fix get_build_tool_path for commands with dashes (e.g. "clang-5.0")
* Hashing semantics for the new build repositories are different than
the old ones, so update those (if the x86 build was not broken before
it is now...)
* OptionalPackages has been updated slightly (removed libtool and git_cvs
from the default images, as they are rarely used nowadays and would pull
in a bunch of dependencies we don't really care for either)
* Removed lib:libqrencode from Haiku package requires (qrencode_kdl is a
static library, the userland libqrencode is not used anywhere in the tree,
as far as I can tell)
* Fix build of JPEG2000 translator after update
* Decouple fluidsynth build machinery and remove from image now that it
is no longer used
* Update repository URL in Repositories preflet
* Eventually BoardSetups and target boards will go away.
* Include all known fdt's in the mmc image
* This gets us closer to target board-less arm
* Changing hardware is as simple as plugging a new fdt
into u-boot's startup script.
* Drop my original rpi1 work. We're targetting ARMv7
minimum.
* beaglebone vs beagleboard
* While the boards are almost the same, they have
diff. FDT's now (more memory, different layout etc)
* Make u-boot script more rpi-like
(depend on u-boot for initial addresses)
* Wasn't working, still doesn't.
EFI boot needs -fpic but all boot code was built with -fno-pic.
This is now set accordingly in HAIKU_BOOT_CCFLAGS and
HAIKU_BOOT_C++FLAGS.
Also setup compile flags for EFI platform.
* Only set HAIKU_BOOT_PLATFORM to bios_ia32 if not defined
* Add gnuefi build feature
* Introduce BOOT_LDFLAGS, and move options for passing to linker
into ArchitectureSetup
* x86_64 compile fixes for warnings in boot loader
* loader/elf.cpp: don't include ELF32 support when targeting EFI
* relocation_func.cpp: copy of the relocation code from gnuefi
to make _relocate extern "C", and avoid including <efilib.h>
* boot_loader_efi.ld: copy of gnuefi's elf_x86_64_efi.lds,
modified to include support for C++ constructors, etc. Keep in
sync with the gnuefi package
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
- As suggested by Ingo, add libshared.a to the architecture name map.
This allows it to be linked by its short name like other frequently
used libraries.
- Adjust all Jamfiles referencing the lib accordingly.
* By setting HDRGRIST to match SOURCE_GRIST in MultiArchDirSetup, the
include scanning in Jam will work properly: the generated header will
have the same grist as what the include scan looks for.
* Remove the now unneeded workaround from netresolv Jamfile.
* The Raspberry pi 2 uses a new SoC which differs slightly
from the Raspberry Pi 1.
* Someday these two board targets could go away when we get
FDT support.
* 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.
* Haiku does not currently provide crtbeginS.o and crtendS.o, so
we fall back to crtbegin.o and crtend.o.
This should not have any ill-effects, as the available compilers on
Haiku do not use __cxa_atexit() yet.
* Gcc is now using __cxa_atexit, so we need to use the crtbegin
and crtend implementations that are meant to be used for shared
libraries. This avoids crashes of servers that load add-ons
(Media-Addon-Server and Print-Server) when shutting down Haiku.
* As executable are shared on Haiku, we use crtbeginS.o and crtendS.o
for those, too.
* To simplify, we even use crtbeginS.o and crtendS.o in the kernel,
but there they don't currently make a difference, as the respective
initialization and cleanup functions are not being invoked by the
kernel.
