Even though building glibc with 64 bit time_t flags is not supported,
and the usual way is to patch the build system to avoid it; some
systems do enable it by default, and it increases the requirements
to build glibc in such cases (it also does not help newcomers when
trying to build glibc).
The conform namespace and linknamespace tests also do not expect
that flag to be set by default, so disable it as well.
Checked with a build/check for major ABI and some (i386, arm,
mipsel, hppa) with a toolchain that has LFS flags by default.
Reviewed-by: DJ Delorie <dj@redhat.com>
Even though building glibc with LFS flags is not supported, and the
the usual way is to patch the build system to avoid it [1]; some system
do enable it by default, and it increases the requirements to build
glibc in such cases (it also does not help newcomers when trying
to build glibc).
The conform namespace and linknamespace tests also do not expect
that flag to be set by default, so disable it as well.
Checked with a build/check for major ABI and some (i386, arm,
mipsel, hppa) with a toolchain that has LFS flags by default.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=31624
Reviewed-by: DJ Delorie <dj@redhat.com>
The -Wp does not work properly if the compiler is configured to enable
fortify by default, since it bypasses the compiler driver (which defines
the fortify flags in this case).
This patch is similar to the one used on Ubuntu [1].
I checked with a build for x86_64-linux-gnu, i686-linux-gnu,
aarch64-linux-gnu, s390x-linux-gnu, and riscv64-linux-gnu with
gcc-13 that enables the fortify by default.
Co-authored-by: Matthias Klose <matthias.klose@canonical.com>
[1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/glibc/tree/debian/patches/ubuntu/fix-fortify-source.patch
Reviewed-by: DJ Delorie <dj@redhat.com>
The purpose of this patch is to add some system calls that (1) aren't
otherwise documented, and (2) are merely redirected to the kernel, so
can refer to their documentation; and define a standard way of doing
so in the future. A more detailed explaination of how system calls
are wrapped is added along with reference to the Linux Man-Pages
project.
Default version of man-pages is in configure.ac but can be overridden
by --with-man-pages=X.Y
Reviewed-by: Alejandro Colomar <alx@kernel.org>
By default, if the C++ toolchain lacks support for static linking,
configure fails to find the C++ header files and the glibc build fails.
The --disable-static-c++-link-check option allows the glibc build to
finish, but static C++ tests will fail if the C++ toolchain doesn't
have the necessary static C++ libraries which may not be easily installed.
Add --disable-static-c++-tests option to skip the static C++ link check
and tests. This fixes BZ #31797.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
The current minimum GCC version of glibc build is GCC 6.2 or newer. But
building i686 glibc with GCC 6.4 on Fedora 40 failed since the C++ header
files couldn't be found which was caused by the static C++ link check
failure due to missing __divmoddi4 which was referenced in i686 libc.a
and added to GCC 7. Add --disable-static-c++-link-check configure option
to disable the static C++ link test. The newly built i686 libc.a can be
used by GCC 6.4 to create static C++ tests. This fixes BZ #31412.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
As discussed at the patch review meeting
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
Reviewed-by: Simon Chopin <simon.chopin@canonical.com>
The aarch64 uses 'trad' for traditional tls and 'desc' for tls
descriptors, but unlike other targets it defaults to 'desc'. The
gnutls2 configure check does not set aarch64 as an ABI that uses
TLS descriptors, which then disable somes stests.
Also rename the internal machinery fron gnu2 to tls descriptors.
Checked on aarch64-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
All the crypt related functions, cryptographic algorithms, and
make requirements are removed, with only the exception of md5
implementation which is moved to locale folder since it is
required by localedef for integrity protection (libc's
locale-reading code does not check these, but localedef does
generate them).
Besides thec code itself, both internal documentation and the
manual is also adjusted. This allows to remove both --enable-crypt
and --enable-nss-crypt configure options.
Checked with a build for all affected ABIs.
Co-authored-by: Zack Weinberg <zack@owlfolio.org>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The option is not activelly tested and has bitrotten, to fix it
would require a lot of work and multiple fixes. A better option
would to evaluate each option and enable the warning if it makes
sense.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The 30379efad1 added _FORTIFY_SOURCE checks without check if compiler
does support all used fortify levels. This patch fixes it by first
checking at configure time the maximum support fortify level and using
it instead of a pre-defined one.
Checked on x86_64 with gcc 11, 12, and 13.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Tested-by: Florian Weimer <fweimer@redhat.com>
We mentioned eventual dropping of libcrypt in the 2.28 NEWS. Actually
put that plan in motion by first disabling building libcrypt by default.
note in NEWS that the library will be dropped completely in a future
release.
Also add a couple of builds into build-many-glibcs.py.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
Bump autoconf requirement to 2.71 to allow regenerating configure on
more recent distributions. autoconf 2.71 has been in Fedora since F36
and is the current version in Debian stable (bookworm). It appears to
be current in Gentoo as well.
All sysdeps configure and preconfigure scripts have also been
regenerated; all changes are trivial transformations that do not affect
functionality.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Add --enable-fortify-source option.
It is now possible to enable fortification through a configure option.
The level may be given as parameter, if none is provided, the configure
script will determine what is the highest level possible that can be set
considering GCC built-ins availability and set it.
If level is explicitly set to 3, configure checks if the compiler
supports the built-in function necessary for it or raise an error if it
isn't.
If the configure option isn't explicitly enabled, it _FORTIFY_SOURCE is
forcibly undefined (and therefore disabled).
The result of the configure checks are new variables, ${fortify_source}
and ${no_fortify_source} that can be used to appropriately populate
CFLAGS.
A dedicated patch will follow to make use of this variable in Makefiles
when necessary.
Updated NEWS and INSTALL.
Adding dedicated x86_64 variant that enables the configuration.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
And make always supported. The configure option was added on glibc 2.25
and some features require it (such as hwcap mask, huge pages support, and
lock elisition tuning). It also simplifies the build permutations.
Changes from v1:
* Remove glibc.rtld.dynamic_sort changes, it is orthogonal and needs
more discussion.
* Cleanup more code.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
It is the default since 2.26 and it has bitrotten over the years,
By using it multiple malloc tests fails:
FAIL: malloc/tst-memalign-2
FAIL: malloc/tst-memalign-2-malloc-hugetlb1
FAIL: malloc/tst-memalign-2-malloc-hugetlb2
FAIL: malloc/tst-memalign-2-mcheck
FAIL: malloc/tst-mxfast-malloc-hugetlb1
FAIL: malloc/tst-mxfast-malloc-hugetlb2
FAIL: malloc/tst-tcfree2
FAIL: malloc/tst-tcfree2-malloc-hugetlb1
FAIL: malloc/tst-tcfree2-malloc-hugetlb2
Checked on x86_64-linux-gnu.
Reviewed-by: DJ Delorie <dj@redhat.com>
Now that there is no need to use a special linker script to hardening
internal data structures, remove the --with-default-link configure
option and associated definitions.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The only way to override LD, AR, OBJCOPY, and GPROF is through
--with-binutils (setting the environments variables on configure is
overridden by LIBC_PROG_BINUTILS).
The build-many-glibcs.py (bmg) glibcs option generates a working config,
but not fully concise (some tools will be set from environment variable,
while other will be set from $CC --print-prog-name). So remove the
environment variable set to always use the "$CC --print-prog-name".
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The assembler is not issued directly, but rather always through CC
wrapper. The binutils version check if done with LD instead.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
When using --with-binutils, the configure might not use the specified
linker or assembler while checking for expected support. Move the
tools check early, before any compiler usage test.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
With clang if the main file is <stdin>, the first non-main-file
dependency is not listed in the -MP output. Although it was fixed
on clang-16 [1], this change adds portability for older version.
[1] ff9576f745
Reviewed-by: Fangrui Song <maskray@google.com>
clang emits an warning when a double alias redirection is used, to warn
the the original symbol will be used even when weak definition is
overridden. However, this is a common pattern for weak_alias, where
multiple alias are set to same symbol.
Reviewed-by: Fangrui Song <maskray@google.com>
Commit 87d583c6e8 replaces the sed script
with an "objdump -f" invocation to determine the 'OUTPUT_FORMAT' bit of
the libc.so linker script.
However, when cross-compiling, for example from x86_64-linux-gnu to
aarch64-linux-gnu, "objdump -f" would report the wrong
format ("elf64-little"). Conversely, "aarch64-linux-gnu-objdump -f"
reports "elf64-littleaarch64" as expected.
This patch changes 'configure.ac' to use AC_CHECK_TOOL rather than
'$CC -print-prog-name=objdump' to determine the value of the OBJDUMP
variable. That way, OBJDUMP is set to TRIPLET-objdump when
cross-compiling for TRIPLET.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
This reverts commit 6f85dbf102.
Once this change hits the release branches, it will require relinking
of all statically linked applications before static dlopen works
again, for the majority of updates on release branches: The NEWS file
is regularly updated with bug references, so the __libc_early_init
suffix changes, and static dlopen cannot find the function anymore.
While this ABI check is still technically correct (we do require
rebuilding & relinking after glibc updates to keep static dlopen
working), it is too drastic for stable release branches.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The files NEWS, include/link.h, and sysdeps/generic/ldsodefs.h
contribute to the version fingerprint used for detection. The
fingerprint can be further refined using the --with-extra-version-id
configure argument.
_dl_call_libc_early_init is replaced with _dl_lookup_libc_early_init.
The new function is used store a pointer to libc.so's
__libc_early_init function in the libc_map_early_init member of the
ld.so namespace structure. This function pointer can then be called
directly, so the separate invocation function is no longer needed.
The versioned symbol lookup needs the symbol versioning data
structures, so the initialization of libc_map and libc_map_early_init
is now done from _dl_check_map_versions, after this information
becomes available. (_dl_map_object_from_fd does not set this up
in time, so the initialization code had to be moved from there.)
This means that the separate initialization code can be removed from
dl_main because _dl_check_map_versions covers all maps, including
the initial executable loaded by the kernel. The lookup still happens
before relocation and the invocation of IFUNC resolvers, so IFUNC
resolvers are protected from ABI mismatch.
The __libc_early_init function pointer is not protected because
so little code runs between the pointer write and the invocation
(only dynamic linker code and IFUNC resolvers).
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The comment indicates that --hash-style=both was used to maintain
compatibility with static dlopen, but we had many internal ABI
changes since then, so this compatiblity does not add value anymore.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
This is necessary to place the libio vtables into the RELRO segment.
New tests elf/tst-relro-ldso and elf/tst-relro-libc are added to
verify that this is what actually happens.
The new tests fail on ia64 due to lack of (default) RELRO support
inbutils, so they are XFAILed there.
-z combreloc has been the default regadless of the architecture since
binutils commit f4d733664aabd7bd78c82895e030ec9779a92809 (2002). The
configure check added in commit fdde83499a (2001) has long been
unneeded.
We can therefore treat HAVE_Z_COMBRELOC as always 1 and delete dead code
paths in dl-machine.h files (many were copied from commit a711b01d34
and ee0cb67ec2).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
configure scripts need to be runnable with a POSIX-compliant /bin/sh.
On many (but not all!) systems, /bin/sh is provided by Bash, so errors
like this aren't spotted. Notably Debian defaults to /bin/sh provided
by dash which doesn't tolerate such bashisms as '=='.
This retains compatibility with bash.
Fixes configure warnings/errors like:
```
checking if compiler warns about alias for function with incompatible types... yes
/var/tmp/portage/sys-libs/glibc-2.34-r10/work/glibc-2.34/configure: 4209: test: xyes: unexpected operator
```
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Sam James <sam@gentoo.org>
When --disable-default-pie is used, all glibc programs and the testsuite
should be built as position dependent executables (non-PIE), regardless
if the build compiler supports PIE or static PIE.
When --disable-default-pie is used, don't build static PIE by default.
This fixes BZ #28780.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Build glibc programs and tests as PIE by default and enable static-pie
automatically if the architecture and toolchain supports it.
Also add a new configuration option --disable-default-pie to prevent
building programs as PIE.
Only the following architectures now have PIE disabled by default
because they do not work at the moment. hppa, ia64, alpha and csky
don't work because the linker is unable to handle a pcrel relocation
generated from PIE objects. The microblaze compiler is currently
failing with an ICE. GNU hurd tries to enable static-pie, which does
not work and hence fails. All these targets have default PIE disabled
at the moment and I have left it to the target maintainers to enable PIE
on their targets.
build-many-glibcs runs clean for all targets. I also tested x86_64 on
Fedora and Ubuntu, to verify that the default build as well as
--disable-default-pie work as expected with both system toolchains.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On Ice Lake and Tiger Lake laptops, some test programs timeout when there
are 3 "make check -j8" runs in parallel. Add --with-timeoutfactor=NUM to
specify an integer to scale the timeout of test programs, which can be
overriden by TIMEOUTFACTOR environment variable.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Since some linkers (for instance lld for i386) does not support it
for all architectures.
Checked on i686-linux-gnu.
Reviewed-by: Fangrui Song <maskray@google.com>
GCC does not print the correct linker when -fuse-ld=lld is used with
the -print-prog-name=ld:
$ gcc -v 2>&1 | tail -n 1
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)
$ gcc
ld
This is different than for gold:
$ gcc -fuse-ld=gold -print-prog-name=ld
ld.gold
Using ld.lld as the static linker name prints the expected result.
This is only required when -fuse-ld=lld is used, if lld is used as
the 'ld' programs (through a symlink) LIBC_PROG_BINUTILS works
as expected.
Checked on x86_64-linux-gnu.
Reviewed-by: Fangrui Song <maskray@google.com>
When LIBC_LINKER_FEATURE is used to check a linker option with the equal
sign, it will likely fail because the LD -v --help output may look like
`-z lam-report=[none|warning|error]` while the needle is something like
`-z lam-report=warning`.
The LD -v --help filter doesn't save much time, so just remove it.
GCC/Clang use local access when referencing a const variable,
so the conftest.so may have no dynamic relocation.
LLD reports `error: unable to insert .foo after .rela.dyn` when the
destination section does not exist.
Use a non-const int to ensure that .rela.dyn exists.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
When using LLD (LLVM linker) as the linker, configure prints a confusing
message.
*** These critical programs are missing or too old: GNU ld
LLD>=13.0.0 can build glibc --enable-static-pie. (8.0.0 needs one
workaround for -Wl,-defsym=_begin=0. 9.0.0 works with
--disable-static-pie).
XFAIL two tests sysdeps/x86/tst-ifunc-isa-* which have the BZ #28154
issue (LLD follows the PowerPC port of GNU ld for ifunc by placing
IRELATIVE relocations in .rela.dyn, triggering a glibc ifunc fragility).
The set of dynamic symbols is the same with GNU ld and LLD,
modulo unused SHN_ABS version node symbols.
For comparison, gold does not support --enable-static-pie
yet (--no-dynamic-linker is unsupported BZ #22221), yet
has 6 failures more than LLD. gold linked libc.so has
larger .dynsym differences with GNU ld and LLD
(non-default version symbols are changed to default versions
by a version script BZ #28196).
