This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: unusable libatomic.so built in certain environments
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Jan Beulich <JBeulich at suse dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 17 Jun 2013 14:30:08 +0000
- Subject: Re: unusable libatomic.so built in certain environments
- References: <51BF2A6002000078000DEDB1 at nat28 dot tlf dot novell dot com>
On Mon, 17 Jun 2013, Jan Beulich wrote:
> expect runtime properties to be taken into account here. And
> for cross builds I'd expect a way to control whether the final
> binary would be using GNU IFUNC symbols rather than just
> making this dependent upon tool chain capabilities.
For cross builds to glibc target I'd quite like a --with-glibc-version or
similar configure option that specifies the (minimum) version of glibc
assumed to be present on the target (strictly, for glibc multilibs, in the
case of a toolchain mixing glibc and non-glibc multilibs, though not all
relevant features effectively support per-multilib configuration).
At present, there is some code in gcc/configure.ac that checks the
target's features.h if this is available at configure time, some checking
bits/wordsize.h for a different purpose, and some that checks for native
configuration and runs ldd --version (for STB_GNU_UNIQUE support), which
isn't cross-friendly at all.
This should be refactored to a single place where a target glibc version
(major and minor version numbers) is determined, which could then use a
new configure option specifying the target version to assume if headers
should not be used to detect it. Such a configure macro could I suppose
be made usable in target library configuration, though the cases I've been
interested in are cases of configuring the compiler itself.
Making a configure option override version detection from target headers
(version detection from ldd --version should simply be avoided completely
and replaced by use of headers / configure option) is useful, in
particular, when building an initial bootstrap compiler before target
glibc headers are available. Specifically, if you want such a compiler to
build a glibc the same as would be the eventual result of an iterative
process of alternating GCC and glibc builds, without needing to override
any autoconf tests in either GCC or glibc with *_cv_* settings, such an
option is needed as I described in
<http://sourceware.org/ml/libc-alpha/2012-09/msg00093.html> to avoid
needing to pass gcc_cv_libc_provides_ssp=yes on some architectures when
configuring the initial bootstrap GCC.
--
Joseph S. Myers
joseph@codesourcery.com