This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unusable libatomic.so built in certain environments


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]