GNU ld gained separate Solaris-specific linker emulations (*_sol2) long
ago. Since their introduction, GCC has preferred them over their
non-*_sol2 counterparts but supported both forms. This has changed for
GCC 16: since all supported versions of GNU ld do support the *_sol2
emulations, GCC now uses them unconditionally.
libtool has also been updated to handle this since libtool 2.4.2 back in
2011. However, that change has only partially been backported to the
heavily patched libtool.m4 in the GCC tree: the sparcv9 part is there,
but the amd64 part is missing for some reason. This causes problems
with some recent binutils changes.
Therefore this patch cherry-picks the libtool patch to bring
Solaris/x86_64 in sync with Solaris/sparcv9 and upstream libtool.
Bootstrapped without regressions on {amd64,i386}-pc-solaris2.11 and
{sparcv9,sparc}-sun-solaris2.11.
2025-09-22 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* libtool.m4: Cherry-pick libtool commit
9196966580f6853a31187a7a3c7e7ff36ef08982.
gcc:
* configure: Regenerate.
libatomic:
* configure: Regenerate.
libbacktrace:
* configure: Regenerate.
libcc1:
* configure: Regenerate.
libffi:
* configure: Regenerate.
libga68:
* configure: Regenerate.
libgcobol:
* configure: Regenerate.
libgfortran:
* configure: Regenerate.
libgm2:
* configure: Regenerate.
libgomp:
* configure: Regenerate.
libgrust:
* configure: Regenerate.
libitm:
* configure: Regenerate.
libobjc:
* configure: Regenerate.
libphobos:
* configure: Regenerate.
libquadmath:
* configure: Regenerate.
libsanitizer:
* configure: Regenerate.
libssp:
* configure: Regenerate.
libstdc++-v3:
* configure: Regenerate.
libvtv:
* configure: Regenerate.
lto-plugin:
* configure: Regenerate.
zlib:
* configure: Regenerate.
commit aef88b83384976e96a8fb287a001588a2277ecd5
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Oct 2 08:53:45 2025 +0800
binutils/GCC: Quote ${COMPILER_FOR_TARGET}
Replace
if test x${COMPILER_FOR_TARGET} = x"\$(CC)"; then
with
if test x"${COMPILER_FOR_TARGET}" = x"\$(CC)"; then
since COMPILER_FOR_TARGET may contain spaces when configuring GCC.
commit 76a693c087c30e8108852928c717399011c6166d
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Sep 30 11:23:58 2025 +0800
binutils: Use AC_TRY_COMPILE to check target clang/gcc
Use AC_TRY_COMPILE to check for the working target clang and gcc when
configuring for cross tools.
commit 77c74294bfc5005204a2de3cc64bbdb2f877be29
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri Sep 26 08:03:01 2025 +0800
binutils: Pass target plugin file to target ar/nm/ranlib
There are 2 kinds of binutils tests:
1. Tests of binutils object files and libraries using the build tools,
like CC, AR, NM and RANLIB.
2. Tests of binutils programs as the target tools, like CC_FOR_TARGET,
AR_FOR_TARGET, NM_FOR_TARGET and RANLIB_FOR_TARGET.
Set AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and
RANLIB_PLUGIN_OPTION_FOR_TARGET to the target compiler plugin file for
target ar/nm/ranlib.
commit 10deea6e2fc1b9ec5818b5fa1bc510c63ff5b2e2
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Sep 23 04:24:00 2025 +0800
Binutils/GCC: Add clang LTO support to AR, NM and RANLIB
Add CLANG_PLUGIN_FILE to find the clang plugin file and pass it to
--plugin for ar, nm and ranlib so that binutils can be built with
clang LTO. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION since
GCC_PLUGIN_OPTION may return the wrong PLUGIN_OPTION with clang.
commit 1fcb94ed750db2ac30d0f0ecc04fa0c7833dd10f
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Thu Sep 18 16:17:14 2025 +0200
Remove remnants of Solaris/PowerPC support
When removing Solaris/PowerPC support, I missed a couple of references.
This patch removes them.
Tested with crosses to ppc-unknown-linux-gnu and powerpc-ibm-aix7.
ChangeLog:
* Makefile.in: Regenerated.
* configure: Likewise.
* Makefile.tpl: Synced from binutils-gdb.
* configure.ac: Likewise.
* libtool.m4: Likewise.
config/ChangeLog:
* clang-plugin.m4: Synced from binutils-gdb.
* gcc-plugin.m4: Likewise.
libbacktrace/ChangeLog:
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
libiberty/ChangeLog:
* aclocal.m4: Regenerated.
* configure: Likewise.
* configure.ac: Synced from binutils-gdb.
zlib/ChangeLog:
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
commit 28ea7ae220a0343ff7fe531ec761bd77d00dcb1c
Author: Matthieu Longo <matthieu.longo@arm.com>
Date: Tue May 28 10:49:45 2024 +0100
autoupdate: replace old version of AC_INIT by the new one
- old AC_INIT by AC_INIT + AC_CONFIG_SRC_DIR
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-3
commit 29496481662736f0a24bfc1daf31dbfc9d2bb7ee
Author: Matthieu Longo <matthieu.longo@arm.com>
Date: Tue May 28 10:49:43 2024 +0100
autoupdate: replace obsolete macros AC_CANONICAL_SYSTEM
- AC_CANONICAL_SYSTEM by:
* AC_CANONICAL_HOST where host, and host_alias are needed
* AC_CANONICAL_TARGET where target_alias is needed
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fCANONICAL_005fTARGET-1
commit d9639e091c77689b10363ecb197466deaa161ade
Author: Maciej W. Rozycki <macro@redhat.com>
Date: Mon Apr 28 18:53:30 2025 +0100
Fix 64-bit BFD detection causing build failures
We have a discrepancy with 64-bit BFD handling across our component
subdirectories leading to link failures such as:
ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
[...]
with some configurations having a 32-bit host and 64-bit BFD, such as:
`--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
other subdirectorses and has been a regression from commit 1d5269c994bf
("unify 64-bit bfd checks").
For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
combined with this logic in bfd/configure.ac:
case ${host64}-${target64}-${want64} in
*true*)
wordsize=64
bfd64_libs='$(BFD64_LIBS)'
all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
[...]
;;
false-false-false)
wordsize=32
all_backends='$(BFD32_BACKENDS)'
;;
esac
where the value of ${wordsize} switches between 32-bit and 64-bit BFD
via these pieces:
#define BFD_ARCH_SIZE @wordsize@
and:
#if BFD_ARCH_SIZE >= 64
#define BFD64
#endif
in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".
Then ${host64} is determined in bfd/configure.ac from the host's word
size, via the host's pointer size:
if test "x${ac_cv_sizeof_void_p}" = "x8"; then
host64=true
fi
And ${target64} is determined in bfd/configure.ac from the target's word
size:
if test ${target_size} = 64; then
target64=true
fi
Where multiple targets have been requested with `--enable-targets=all'
the presence of any 64-bit target will set "true" here.
Finally ${want64} is set according to `--enable-64-bit-bfd' user option
with an arrangement involving BFD_64_BIT:
BFD_64_BIT
if test $enable_64_bit_bfd = yes ; then
want64=true
else
want64=false
fi
which also, redundantly, checks and sets its result upon the host's word
size. Lastly ${want64} is also selectively set by target fragments in
bfd/config.bfd, which mostly if not completely overlaps with ${target64}
setting as described above.
Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
notice that BFD is 64-bit and do not enable their 64-bit handling where
the host requested is 32-bit and 64-bit BFD has been enabled other than
with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c
enables calls to its numerous own 64-bit backends by checking the BFD64
macro from "bfd.h", however does not actually enable said backends in
its Makefile. Hence the link errors quoted above.
Address the problem then by moving the `--enable-64-bit-bfd' option back
to bfd/configure.ac and remove the call to BFD_64_BIT from there and
then rewrite the macro in terms of checking for the presence of BFD64
macro in "bfd.h", which is the canonical way of determining whether BFD
is 64-bit or not.
Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
fragment used to before the problematic commit:
if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then
run the preprocessor on "bfd.h", which allows to invoke the macro from
configure.ac files placed in subdirectories located at deeper levels, by
relying on the preprocessor's search path.
This requires however that the invokers rely on `all-bfd' rather than
`configure-bfd' for their `configure' invocation stage, because "bfd.h"
is made by `make all' rather than `configure' in bfd/.
Do not cache the result of this check however, as reconfiguring a tree
such as to flip `--enable-64-bit-bfd' on or to change a secondary target
may affect BFD64 and we have no access to information about secondary
targets in BFD_64_BIT.
Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
anywhere.
Last but not least remove the hack from gdb/configure.ac to fail builds
for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds
complete successfully now, having enabled 64-bit BFD implicitly.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Alan Modra <amodra@gmail.com>
Approved-By: Luis Machado <luis.machado@arm.com>
* Makefile.def: Synced from binutils-gdb.
* Makefile.in: Regenerated.
commit 319719bb2921e978738acd408e6b16dabf0e7f5e
Author: Tom Tromey <tom@tromey.com>
Date: Thu Mar 21 17:12:23 2024 -0600
Revert "Pass GUILE down to subdirectories"
This reverts commit b7e5a29602.
This patch caused problems for some users when building gdb, because
it would cause 'guild' to be invoked with the wrong versin of guile.
On the whole it seems simpler to just back this out.
I'm checking this in to the binutils-gdb repository in the interest of
fixing the build for Andrew. No one has responded to the identical
patch sent to gcc-patches, but I will ping it there.
commit da48217f315084097ef25226c0acab3bbd55ebd3
Author: Simon Marchi <simon.marchi@efficios.com>
Date: Thu Mar 14 13:39:18 2024 -0400
gdbserver/linux: probe for libiconv in configure
Make gdbserver's build system locate libiconv when building for Linux.
Commit 07b3255c3bae ("Filter invalid encodings from Linux thread names")
make libiconv madantory for building gdbserver on Linux.
While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a
toolchain generated with crosstool-ng), I got:
/home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory
48 | #include <iconv.h>
| ^~~~~~~~~
I downloaded GNU libiconv, built it for that host, and installed it in
an arbitrary directory. I had to modify the gdbserver build system to
locate libiconv and use it, the result is this patch.
I eventually found that crosstool-ng has a config option to make uclibc
provide an implementation of iconv, which is of course much easier. But
given that this patch is now written, I think it would be worth merging
it, it could help some people who do not have iconv built-in their libc
in the future (and may not have the luxury of rebuilding their libc like
I do).
Using AM_ICONV in configure.ac adds these options for configure (the
same we have for gdb):
--with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib
--without-libiconv-prefix don't search for libiconv in includedir and libdir
--with-libiconv-type=TYPE type of library to search for (auto/static/shared)
It sets the `LIBICONV` variable with whatever is needed to link with
libiconv, and adds the necessary `-I` flag to `CPPFLAGS`.
To avoid unnecessarily linking against libiconv on hosts that don't need
it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the
host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`.
Since libiconv is a hard requirement for Linux hosts, error out if it is
not found.
The bits in acinclude.m4 are similar to what we have in
gdb/acinclude.m4.
Update the top-level build system to support building against an in-tree
libiconv (I did not test this part though). Something tells me that the
all-gdbserver dependency on all-libiconv is unnecessary, since there is
already a dependency of configure-gdbserver on all-libiconv (and
all-gdbserver surely depends on configure-gdbserver). I just copied
what's done for GDB though.
* Makefile.def: Synced from binutils-gdb.
* Makefile.tpl: Likewise.
* configure.ac: Likewise.
* Makefile.in: Regenerated.
* configure: Likewise.
config/
* acx.m4: Synced from binutils-gdb.
* lthostflags.m4: Likewise.
libbacktrace/
* configure.ac: Synced from binutils-gdb.
* configure: Regenerated.
zlib/
* configure.ac: Synced from binutils-gdb.
* configure: Regenerated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
It seems that at least when cross-compiling at least collect2 pulls
in objects from libbacktrace.a which is linked via LIBDEPS. But
libbacktrace for the host is only built -fPIC with --enable-host-shared
but not -fPIE with --enable-host-pie so this fails. The following
teaches libbacktrace about --enable-host-pie and handles it similar
to libcpp.
PR bootstrap/119680
libbacktrace/
* configure.ac (--enable-host-pie): Handle by setting PIC_FLAG
to -fPIE.
* configure: Regenerate.
Patch from pgerell@github.
* elf.c (elf_fetch_bits): Add casts to avoid potentially shifting
a value farther than its type size.
(elf_fetch_bits_backward): Likewise.
(elf_uncompress_lzma_block): Likewise.
(elf_uncompress_lzma): Likewise.
Older versions of the Arm architecture lack support for __sync
operations directly in hardware and require calls into appropriate
operating-system hooks. But such hooks obviously don't exist in a
freestanding environment.
Consquently, it is incorrect to assume during configure that such
functions will exist and we need a configure-time check to determine
whether or not these routines will work.
libbacktrace:
* configure.ac: Always check if the compiler supports __sync
operations.
* configure: Regenerated.
PR 117812 reports that testing GCC with zstd 1.3.4 fails because
ZSTD_CLEVEL_DEFAULT is not defined, so avoid using it.
PR libbacktrace/117812
* zstdtest.c (test_large): Use 3 rather than ZSTD_CLEVEL_DEFAULT
Also convert some FALLTHROUGH comments to ATTRIBUTE_FALLTHROUGH.
* internal.h: Use __has_attribute to check for fallthrough
attribute.
* elf.c (elf_zstd_decompress): Use ATTRIBUTE_FALLTHROUGH rather
than a FALLTHROUGH comment.
We could get an infinite recursion in an odd case in which a
.gnu_debugdata section was added to a debug file, and mini_debuginfo
was put into the debug file, and the debug file was put into a
/usr/lib/debug directory to be found by build ID. This combination
doesn't really make sense but we shouldn't get an infinite recursion.
* elf.c (elf_add): Don't use .gnu_debugdata if we are already
reading a debuginfo file.
* Makefile.am (m2test_*): New test targets.
(CHECK_PROGRAMS): Add m2test.
(MAKETESTS): Add m2test_minidebug2.
(%_minidebug2): New pattern.
(CLEANFILES): Remove minidebug2 files.
* Makefile.in: Regenerate.
