On Haiku, this is now available as part of libbsd. The build
system for libbacktrace does not know about this library. In a regular
build this does not matter, as the test in the configure script will
fail to compile. However, when libbacktrace is built as a target
library, only the existence of the method in link.h is tested, which
will succeed.
This lead to libgfortan.so having undefined references.
See: https://github.com/haikuports/haikuports/issues/9241
Change-Id: I576d7802d43e11787b3bc1d09c89a42bf982dc3b
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/6950
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In 9866b1a the '-rdynamic' option was added to GCC 11 for Haiku, with the
intention of it being a no-op. Potentially the behavior has changed between GCC
11 and 13, and the previous approach did not work, given that it gave an error
that the argument was not supported.
This change tries to re-enable -rdynamic with the explicit intention of
ignoring it.
Change-Id: Ice19b30cafe0f1e1289a04818c9d01bf0ea7de09
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/6814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Trung Nguyen <trungnt282910@gmail.com>
Dependencies (not updated since 13.1.0):
* GMP 6.2.1
* ISL 0.24
* MPL 1.2.1
* MPFR 4.1.0
The dependencies were pulled in by running the ./contrib/download_prerequisites script.
Updated dependencies:
* GMP 6.2.1
* ISL 0.24
* MPL 1.2.1
* MPFR 4.1.0
The dependencies were pulled in by running the ./contrib/download_prerequisites script and then
manually removing the symbolic links and archives, and renaming the directories (i.e mv isl-0.24 to isl)
* fno-omit-frame-pointer is enabled by default on all architectures
* This provides easier/faster backtraces at the cost of lower
performance (Fedora benchmarks show between no difference and 10%
depending on the scenario, with most things being around 2%)
* 32-bit x86 is not changed, because it has very few registes compared
to other architectures, the performance cost would be even worse there
(Fedora backed out the change on 32bit x86 as well)
On ARM and RISV-V, unwinding without a frame pointer is difficult (on
ARM this is due to the architecture defining mainly the link register as
a way to chaun functions, there is no fixed stack structure, on RISC-V I
don't know what the situation is but I expect there is something
similar). So on these architectures, the frame pointer should always be
enabled. On PPC, there is an hardware register doing pretty much the
frame pointer role, and that can't be disabled. On other architectures
(m68k and x86_64), it is mostly a matter of balance between the
performance cost and the ease of getting backtraces (for example for
realtime profiling). This can now easily be tweaked per architecture as
needed, with frame pointers being enabled by default (a reasonable
choice for someone starting a new architecture, ease of debugging is
more important than performance then).
Note that code that enables -fomit-frame-pointer explicitly can still do
that if needed, so the bad cases where the performance cost is very high
can be handled in this way.
Source for Fedora benchmarks: https://pagure.io/fesco/issue/2817#comment-826636
Change-Id: Iea9b8fec51adb192052f55cc49a8c1d922e27aa4
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/4368
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: David Karoly <karolyd577@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Fixes the
error: use of undeclared identifier 'HOST_HOOKS_INITIALIZER'
on Apple with M1 (silicon) chip
Fixes#17457
Change-Id: Id3b550c0d875d521539923ab7ecac0006715b7d6
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/6191
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku binaries already export their symbols, which is the same
behaviour as using `-rdynamic` on other platforms; so add
`-rdynamic` as a no-op to simplify porting software that depends
on the behaviour of `-rdynamic`.
Droped the `__cdecl` and `__stdcall` built-in macros except for
32-bit i386 compilation.
These macros refer to calling conventions that are specific to
32-bit x86 and have no meaning for other architectures. Using them
does nothing except producing a compiler warning.
These macros were present in BeOS times but only for i386. At the
time of writing, they are not used anywhere throughout the Haiku
source tree, and some HaikuPorts recipes even have to provide
workarounds for these macros' prescence.
Change-Id: I70369a64a71d8e29ccc0bd6282ba93832c1a6adf
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/6384
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
* We decided to go with the more standadard __riscv, __riscv_xlen
* No references to these in Haiku source code
Change-Id: Ia3aa9c239a5313f404fad1163fac3334a10f0eb4
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/6199
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This merge is made using the "ours" strategy so it does not change
anything to the master branch content. This is here only to make it
easier to do the next updates of binutils.
The process to update the binutils vendor branch is:
git checkout vendor-binutils # Work on the vendor branch
git rm -rf binutils # Delete the previous binutils version
wget http://.../binutils.tar # Download the new binutils version
tar xvf binutils.tar # Extract the new binutils version
mv binutils-2.36 binutils # Move the extracted directory in the correct place
git add binutils # Add the new files
git status # Make sure everything is ok
git commit -m "import binutils 2.36" # Commit the new version
git checkout master
git merge vendor-binutils # Merge the changes in the master branch
# Resolve conflicts as needed
When this process is followed, it is a lot easier to compare our branch
with the original sources:
git diff binutils/ vendor-binutils # Compare the binutils directory with the upstream version
There is also less risk to miss a patch when merging the changes,
because Git will keep track of the changes.
This process is named "vendor branches" and originates from SVN. It had
been used until binutils 2.28.1, but the next two updates were not done
this way. This commits sets us up to use this workflow again.
This creates a PT_EH_FRAME section in Haiku binaries,
allowing 3rd party unwind libraries (libunwind) to obtain
frame information for unwind procedures.
Change-Id: If475909d182bcac11024ebbc8220456733330fe8
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/5434
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Should fix the root cause of https://github.com/haikuports/haikuports/issues/4316
Some CPU architectures do similar things (for example because they don't
support PIC at all). So it should be fine to do it here. See for example
gcc/gcc/config/gcn/gcn.c
Change-Id: Ie23e4ece0d09c1083ad3c3bf43756f3207bbdafe
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/5194
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Results in an internal compiler error: in do_spec_1, at gcc.c:5971
* %{!o*:-o %b} is "no output flag to linker, add one with input name"
* ld blah.o becomes ld blah.o -o blah
* We really shouldn't be playing with this in linker specs... It also
breaks on gcc 11.
Change-Id: I63d0afecd16f25423874419c0ac9496404b2069e
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/4834
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
There was a comma in compile_commands.json after the last entry what
prevented from using file directly in some tools.
Test plan:
verified new compile_commands.json with "python3 -m json.tool compile_commands.json"
Change-Id: I6c2582f7285a3409d95081a93f3c05b5cc9322b9
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/4671
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Version string was not updated for 10 years, but there were some changes made.
This commit updates the date to avoid confusion.
Test plan:
~/buildtools/jam> jam -v
Jam 2.5-haiku-20211020. OS=HAIKU. Copyright 1993-2002 Christopher Seiwald.
Change-Id: Ieea0ed2a533396f664948f58798acee0f6c811e9
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/4618
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Running "./jam0 install" installed jam in /boot/common/bin/ which
is no longer used. Other directories also looked outdated so they
are updated too.
Test plan:
1. make
2. ./jam0 install
Install /boot/system/non-packaged/bin/jam
3. which jam
/boot/system/non-packaged/bin/jam
Change-Id: I69c719eab0bd211f545c17337e3bc73bb1ab78fe
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/4617
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The call of make in buildtools/jam produces the following output:
LINKLIBS= ./jam0
...patience...
...found 271 target(s)...
...updating 33 target(s)...
MkDir1 bin.linuxx86
Cc bin.linuxx86/builtins.o
< reduced output >
Cc bin.linuxx86/variable.o
Archive bin.linuxx86/libjam.a
ar: `u' modifier ignored since `D' is the default (see `U')
ar: creating bin.linuxx86/libjam.a
...
'make' bootstraps 'jam0' which calls 'ar' to create the static library 'libjam.a'.
The call looks like this:
ar ru bin.linuxx86/libjam.a bin.linuxx86/builtins.o <reduced output> bin.linuxx86/variable.o
The modifier 'u' gets ignored.
The underlying cause is that the build was done in deterministic mode ('D'), a.o. NOT using timestamps, which is completely fine.
But because of this the archiver tool (ar) can never update files in the archive based on timestamps.
"ru" means replace files (flag 'r') only if they are updated (flag suffix 'u') based on timestamps.
This patch removes the flag suffix 'u'.
Change-Id: I57fa2d50c2081ee66d1b71648714e773ecb7cd59
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/4419
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
