Commit Graph

138 Commits

Author SHA1 Message Date
Joseph Myers
4dcbbc3b28 Require GCC 6.2 or later to build glibc.
As discussed during development for glibc 2.29, when we increased the
required minimum GCC version for building glibc to GCC 5, working
purely based on the times at which such requirements have been
increased in the past it would be appropriate for glibc 2.30 to
require GCC 6 (matching GCC 4.9 having been required for glibc 2.26).
Naming 6.2 specifically as the minimum version then means a separate
version requirement no longer needs to be specified for powerpc64le.

Thus, this patch increases the minimum to 6.2, removing the
documentation of the separate requirement for powerpc64le.  It does
not remove the powerpc64le configure test, or any __GNUC_PREREQ that
could be removed as not being in installed headers or files shared
with gnulib; I think such cleanups are best done separately.

Tested for x86_64.

	* configure.ac (libc_cv_compiler_ok): Require GCC 6.2 or later.
	* configure: Regenerated.
	* manual/install.texi (Tools for Compilation): Update minimum GCC
	version.
	* INSTALL: Regenerated.
2019-02-01 16:27:44 +00:00
Siddhesh Poyarekar
330c9d0db1 Prepare for 2.29 release
* NEWS: Add the list of bugs fixed in 2.29.
	* manual/contrib.texi: Update contributors list with some more
	names.
 	* manual/install.texi: Update latest versions of packages
 	tested.
 	* INSTALL: Regenerated.
2019-01-31 22:01:21 +05:30
Joseph Myers
192963be49 Require GCC 5 or later to build glibc (bug 23993).
We know that building glibc with GCC 4.9 is broken on various
platforms (bug 23993).  As it's more than a year since we last
increased the minimum GCC version to build glibc, this patch changes
the requirement to be GCC 5 or later (indeed, based on 4.9 having been
required for building 2.26, it would be consistent in terms of timing
to require GCC 6 or later from the 2.30 release onwards).  It
deliberately just updates the configure test and corresponding
documentation, leaving removal of no-longer-needed __GNUC_PREREQ tests
for a separate patch.

In the NEWS entry, the requirement for a newer GCC version for
powerpc64le is reiterated (as in the entry for the 4.9 requirement in
2.26) to avoid suggesting the version requirement there has gone down.
(If that version goes up further as part of support for binary128 long
double, of course the wording would change at that time.)

Tested for x86_64.

	[BZ #23993]
	* configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
	* configure: Regenerated.
	* manual/install.texi (Tools for Compilation): Update minimum GCC
	version.
	* INSTALL: Regenerated.
2018-12-21 17:53:40 +00:00
Florian Weimer
053c52b177 locale: Rewrite locale/gen-translit.pl in Python
This commit does not change the generated output file.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2018-12-18 11:36:29 +01:00
Joseph Myers
c6982f7efc Patch to require Python 3.4 or later to build glibc.
This patch makes Python 3.4 or later a required tool for building
glibc, so allowing changes of awk, perl etc. code used in the build
and test to Python code without any such changes needing makefile
conditionals or to handle older Python versions.

This patch makes the configure test for Python check the version and
give an error if Python is missing or too old, and removes makefile
conditionals that are no longer needed.  It does not itself convert
any code from another language to Python, and does not remove any
compatibility with older Python versions from existing scripts.

Tested for x86_64.

	* configure.ac (PYTHON_PROG): Use AC_CHECK_PROG_VER.  Set
	critic_missing for versions before 3.4.
	* configure: Regenerated.
	* manual/install.texi (Tools for Compilation): Document
	requirement for Python to build glibc.
	* INSTALL: Regenerated.
	* Rules [PYTHON]: Make code unconditional.
	* benchtests/Makefile [PYTHON]: Likewise.
	* conform/Makefile [PYTHON]: Likewise.
	* manual/Makefile [PYTHON]: Likewise.
	* math/Makefile [PYTHON]: Likewise.
2018-10-29 15:28:05 +00:00
Joseph Myers
b71ac2b9ce Use gen-libm-test.py to generate ulps table for manual.
This patch extends gen-libm-test.py to generate the ulps table for the
manual, so meaning there is only a single ulps file parser needed and
another Perl script is eliminated.  As with the introduction of
gen-libm-test.py, this is designed to generate exactly the same
libm-err.texi as libm-err-tab.pl did.  (gen-libm-test.py is still
shorter in lines than the old gen-libm-test.pl even after this patch.)
Note that this introduces a Python dependency for building the manual,
which is thus noted in install.texi and NEWS.

Tested building html / info / pdf versions of the manual.

	* math/gen-libm-test.py: Import os.
	(ALL_FLOATS_MANUAL): New constant.
	(ALL_FLOATS_SUFFIX): Likewise.
	(Ulps.all_functions): New function.
	(real_all_ulps): Likewise.
	(generate_err_table_sub): Likewise.
	(generate_err_table): Likewise.
	(main): Handle -s and -m options.
	* manual/libm-err-tab.pl: Remove.
	* manual/Makefile ($(objpfx)stamp-libm-err): Use gen-libm-test.py
	instead of libm-err-tab.pl.
	[$(PERL) != no]: Change condition to [$(if $(PYTHON),$(PERL),no)
	!= no].
	* manual/install.texi (Tools for Compilation): Document
	requirement for Python to build manual.
	* INSTALL: Regenerated.
2018-10-24 20:34:31 +00:00
Andreas Schwab
462d348caa Don't build libnsl for new ABIs
For architectures and ABIs that are added in version 2.29 or later the
option --enable-obsolete-nsl is no longer available, and no libnsl
compatibility library is built.
2018-09-24 10:23:10 +02:00
Florian Weimer
6413fcde4f Add --with-nonshared-cflags option to configure 2018-08-17 11:44:39 +02:00
Joseph Myers
3c1622eb77 Update install.texi documentation of uses of Perl and Python.
The install.texi documentation of uses of Perl and Python is
substantially out of date.

The description of Perl is "to test the installation" (which I
interpret as referring to test-installation.pl), but it's used for
more tests than that, and to build the manual, and to regenerate one
file in the source tree.

The description of Python is only for pretty-printer tests, but it's
used for other tests / benchmarks as well (and for other internal uses
such as updating Unicode data, for which we already require Python 3,
but I think install.texi only needs to describe uses from the main
glibc Makefiles).

This patch updates the descriptions of what those tools are used for.
The Python information (and information about other tools for testing
pretty printers) was awkwardly in the middle of the general
description of building and testing glibc, rather than with the rest
of information about tools used in glibc build and test; this patch
moves the information about those tools into the main list.

Tested with regeneration of INSTALL as well as "make info" and "make
pdf".

	* manual/install.texi (Configuring and compiling): Do not list
	tools used for testing pretty printers here.
	(Tools for Compilation): List Python, PExpect and GDB here.
	Update descriptions of uses of Perl and Python.
	* INSTALL: Regenerate.
2018-08-13 17:20:46 +00:00
Carlos O'Donell
08a5ee14c6 Add convenience target 'install-locale-files'.
The convenience install target 'install-locale-files' is created
to allow distributions to install all of the SUPPORTED locales as
files instead of into the locale-archive.

You invoke the new convenience target like this:
make localedata/install-locale-files DESTDIR=<prefix>
2018-08-02 15:31:12 -04:00
Carlos O'Donell
f650932b34 Update tooling versions verified to work with glibc. 2018-07-31 16:37:07 -04:00
H.J. Lu
e84bd8514c INSTALL: Add a note for Intel CET status
* NEWS: Add a note for Intel CET status.
	* manual/install.texi: Likewise.
	* INSTALL: Regenerated.
2018-07-19 12:05:10 -07:00
H.J. Lu
e6c695099b Intel CET: Document --enable-cet
* NEWS: Mention --enable-cet.
	* manual/install.texi: Document --enable-cet.
	* INSTALL: Regenerated.
2018-07-18 09:52:53 -07:00
Florian Weimer
f2873d2da0 testrun.sh: Implement --tool=strace, --tool=valgrind
$(file …) appears to be the only convenient way to create files
with newlines and make substitution variables.  This needs make 4.0
(released in 2013), so update the requirement to match.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2018-07-04 15:30:45 +02:00
Zack Weinberg
e69d994a63 New configure option --disable-crypt.
Some Linux distributions are experimenting with a new, separately
maintained and hopefully more agile implementation of the crypt
API.  To facilitate this, add a configure option which disables
glibc's embedded libcrypt.  When this option is given, libcrypt.*
and crypt.h will not be built nor installed.
2018-06-29 16:53:47 +02:00
Joseph Myers
db9881ecd7 Document use of CC and CFLAGS in more detail (bug 20980, bug 21234).
There are some bug reports from people setting CFLAGS not including a
-O option and then being confused when the build fails.  This patch
addresses this by documenting the proper use of CC and CFLAGS in more
detail - saying what options should go where and specifying the
requirement to compile with optimization.

The previous text incorrectly used @var markup with CC and CFLAGS.
The correct markup for environment variables is @env, but it's also
the case that passing such variables explicitly on the configure
command line is preferred to passing them in the environment, so this
patch changes the documentation to describe passing them on the
command line (and uses @code).

In many cases putting options in the wrong place may in fact work, but
I believe what I've specified is the correct rule for which options to
put where.

	[BZ #20980]
	[BZ #21234]
	* manual/install.texi (Configuring and compiling): Describe
	passing CC and CFLAGS on configure command line, not as
	environment variables.  Use @code markup on those variables.
	Specify what options go in CC and what go in CFLAGS.  Note the
	requirement to compile with optimization.
	* INSTALL: Regenerated.
2018-02-15 23:48:47 +00:00
Dmitry V. Levin
d9f442ce56 Fix typo in the previous commit
The version of GCC was 7.3, not 7.3.1.
2018-01-31 23:13:00 +00:00
Dmitry V. Levin
9349311964 Update information about the newest versions of tools used to build glibc
* manual/install.texi (Tools for Compilation): Update the newest
versions of gcc, binutils, texinfo, gawk, bison, and sed.
* INSTALL: Regenerated.
2018-01-31 14:20:10 +00:00
H.J. Lu
126adc89d8 Document that --enable-static-pie implies PIE
To build static PIE, all .o files are compiled with -fPIE.  Since
--enable-static-pie is designed to provide additional security hardening
benefits, it also implies that glibc programs and tests are created as
dynamic position independent executables (PIE) by default for better
security hardening.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

	* manual/install.texi: Document that --enable-static-pie
	implies PIE.
	* INSTALL: Regenerated.
2017-12-19 13:51:16 -08:00
H.J. Lu
9d7a3741c9 Add --enable-static-pie configure option to build static PIE [BZ #19574]
Static PIE extends address space layout randomization to static
executables.  It provides additional security hardening benefits at
the cost of some memory and performance.

Dynamic linker, ld.so, is a standalone program which can be loaded at
any address.  This patch adds a configure option, --enable-static-pie,
to embed the part of ld.so in static executable to create static position
independent executable (static PIE).  A static PIE is similar to static
executable, but can be loaded at any address without help from a dynamic
linker.  When --enable-static-pie is used to configure glibc, libc.a is
built as PIE and all static executables, including tests, are built as
static PIE.  The resulting libc.a can be used together with GCC 8 or
above to build static PIE with the compiler option, -static-pie.  But
GCC 8 isn't required to build glibc with --enable-static-pie.  Only GCC
with PIE support is needed.  When an older GCC is used to build glibc
with --enable-static-pie, proper input files are passed to linker to
create static executables as static PIE, together with "-z text" to
prevent dynamic relocations in read-only segments, which are not allowed
in static PIE.

The following changes are made for static PIE:

1. Add a new function, _dl_relocate_static_pie, to:
   a. Get the run-time load address.
   b. Read the dynamic section.
   c. Perform dynamic relocations.
Dynamic linker also performs these steps.  But static PIE doesn't load
any shared objects.
2. Call _dl_relocate_static_pie at entrance of LIBC_START_MAIN in
libc.a.  crt1.o, which is used to create dynamic and non-PIE static
executables, is updated to include a dummy _dl_relocate_static_pie.
rcrt1.o is added to create static PIE, which will link in the real
_dl_relocate_static_pie.  grcrt1.o is also added to create static PIE
with -pg.  GCC 8 has been updated to support rcrt1.o and grcrt1.o for
static PIE.

Static PIE can work on all architectures which support PIE, provided:

1. Target must support accessing of local functions without dynamic
relocations, which is needed in start.S to call __libc_start_main with
function addresses of __libc_csu_init, __libc_csu_fini and main.  All
functions in static PIE are local functions.  If PIE start.S can't reach
main () defined in a shared object, the code sequence:

	pass address of local_main to __libc_start_main
	...

local_main:
	tail call to main via PLT

can be used.
2. start.S is updated to check PIC instead SHARED for PIC code path and
avoid dynamic relocation, when PIC is defined and SHARED isn't defined,
to support static PIE.
3. All assembly codes are updated check PIC instead SHARED for PIC code
path to avoid dynamic relocations in read-only sections.
4. All assembly codes are updated check SHARED instead PIC for static
symbol name.
5. elf_machine_load_address in dl-machine.h are updated to support static
PIE.
6. __brk works without TLS nor dynamic relocations in read-only section
so that it can be used by __libc_setup_tls to initializes TLS in static
PIE.

NB: When glibc is built with GCC defaulted to PIE, libc.a is compiled
with -fPIE, regardless if --enable-static-pie is used to configure glibc.
When glibc is configured with --enable-static-pie, libc.a is compiled
with -fPIE, regardless whether GCC defaults to PIE or not.  The same
libc.a can be used to build both static executable and static PIE.
There is no need for separate PIE copy of libc.a.

On x86-64, the normal static sln:

   text	   data	    bss	    dec	    hex	filename
 625425	   8284	   5456	 639165	  9c0bd	elf/sln

the static PIE sln:

   text	   data	    bss	    dec	    hex	filename
 657626	  20636	   5392	 683654	  a6e86	elf/sln

The code size is increased by 5% and the binary size is increased by 7%.

Linker requirements to build glibc with --enable-static-pie:

1. Linker supports --no-dynamic-linker to remove PT_INTERP segment from
static PIE.
2. Linker can create working static PIE.  The x86-64 linker needs the
fix for

https://sourceware.org/bugzilla/show_bug.cgi?id=21782

The i386 linker needs to be able to convert "movl main@GOT(%ebx), %eax"
to "leal main@GOTOFF(%ebx), %eax" if main is defined locally.

Binutils 2.29 or above are OK for i686 and x86-64.  But linker status for
other targets need to be verified.

3. Linker should resolve undefined weak symbols to 0 in static PIE:

https://sourceware.org/bugzilla/show_bug.cgi?id=22269

4. Many ELF backend linkers incorrectly check bfd_link_pic for TLS
relocations, which should check bfd_link_executable instead:

https://sourceware.org/bugzilla/show_bug.cgi?id=22263

Tested on aarch64, i686 and x86-64.

Using GCC 7 and binutils master branch, build-many-glibcs.py with
--enable-static-pie with all patches for static PIE applied have the
following build successes:

PASS: glibcs-aarch64_be-linux-gnu build
PASS: glibcs-aarch64-linux-gnu build
PASS: glibcs-armeb-linux-gnueabi-be8 build
PASS: glibcs-armeb-linux-gnueabi build
PASS: glibcs-armeb-linux-gnueabihf-be8 build
PASS: glibcs-armeb-linux-gnueabihf build
PASS: glibcs-arm-linux-gnueabi build
PASS: glibcs-arm-linux-gnueabihf build
PASS: glibcs-arm-linux-gnueabihf-v7a build
PASS: glibcs-arm-linux-gnueabihf-v7a-disable-multi-arch build
PASS: glibcs-m68k-linux-gnu build
PASS: glibcs-microblazeel-linux-gnu build
PASS: glibcs-microblaze-linux-gnu build
PASS: glibcs-mips64el-linux-gnu-n32 build
PASS: glibcs-mips64el-linux-gnu-n32-nan2008 build
PASS: glibcs-mips64el-linux-gnu-n32-nan2008-soft build
PASS: glibcs-mips64el-linux-gnu-n32-soft build
PASS: glibcs-mips64el-linux-gnu-n64 build
PASS: glibcs-mips64el-linux-gnu-n64-nan2008 build
PASS: glibcs-mips64el-linux-gnu-n64-nan2008-soft build
PASS: glibcs-mips64el-linux-gnu-n64-soft build
PASS: glibcs-mips64-linux-gnu-n32 build
PASS: glibcs-mips64-linux-gnu-n32-nan2008 build
PASS: glibcs-mips64-linux-gnu-n32-nan2008-soft build
PASS: glibcs-mips64-linux-gnu-n32-soft build
PASS: glibcs-mips64-linux-gnu-n64 build
PASS: glibcs-mips64-linux-gnu-n64-nan2008 build
PASS: glibcs-mips64-linux-gnu-n64-nan2008-soft build
PASS: glibcs-mips64-linux-gnu-n64-soft build
PASS: glibcs-mipsel-linux-gnu build
PASS: glibcs-mipsel-linux-gnu-nan2008 build
PASS: glibcs-mipsel-linux-gnu-nan2008-soft build
PASS: glibcs-mipsel-linux-gnu-soft build
PASS: glibcs-mips-linux-gnu build
PASS: glibcs-mips-linux-gnu-nan2008 build
PASS: glibcs-mips-linux-gnu-nan2008-soft build
PASS: glibcs-mips-linux-gnu-soft build
PASS: glibcs-nios2-linux-gnu build
PASS: glibcs-powerpc64le-linux-gnu build
PASS: glibcs-powerpc64-linux-gnu build
PASS: glibcs-tilegxbe-linux-gnu-32 build
PASS: glibcs-tilegxbe-linux-gnu build
PASS: glibcs-tilegx-linux-gnu-32 build
PASS: glibcs-tilegx-linux-gnu build
PASS: glibcs-tilepro-linux-gnu build

and the following build failures:

FAIL: glibcs-alpha-linux-gnu build

elf/sln is failed to link due to:

assertion fail bfd/elf64-alpha.c:4125

This is caused by linker bug and/or non-PIC code in PIE libc.a.

FAIL: glibcs-hppa-linux-gnu build

elf/sln is failed to link due to:

collect2: fatal error: ld terminated with signal 11 [Segmentation fault]

https://sourceware.org/bugzilla/show_bug.cgi?id=22537

FAIL: glibcs-ia64-linux-gnu build

elf/sln is failed to link due to:

collect2: fatal error: ld terminated with signal 11 [Segmentation fault]

FAIL: glibcs-powerpc-linux-gnu build
FAIL: glibcs-powerpc-linux-gnu-soft build
FAIL: glibcs-powerpc-linux-gnuspe build
FAIL: glibcs-powerpc-linux-gnuspe-e500v1 build

elf/sln is failed to link due to:

ld: read-only segment has dynamic relocations.

This is caused by linker bug and/or non-PIC code in PIE libc.a.  See:

https://sourceware.org/bugzilla/show_bug.cgi?id=22264

FAIL: glibcs-powerpc-linux-gnu-power4 build

elf/sln is failed to link due to:

findlocale.c:96:(.text+0x22c): @local call to ifunc memchr

This is caused by linker bug and/or non-PIC code in PIE libc.a.

FAIL: glibcs-s390-linux-gnu build

elf/sln is failed to link due to:

collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped

assertion fail bfd/elflink.c:14299

This is caused by linker bug and/or non-PIC code in PIE libc.a.

FAIL: glibcs-sh3eb-linux-gnu build
FAIL: glibcs-sh3-linux-gnu build
FAIL: glibcs-sh4eb-linux-gnu build
FAIL: glibcs-sh4eb-linux-gnu-soft build
FAIL: glibcs-sh4-linux-gnu build
FAIL: glibcs-sh4-linux-gnu-soft build

elf/sln is failed to link due to:

ld: read-only segment has dynamic relocations.

This is caused by linker bug and/or non-PIC code in PIE libc.a.  See:

https://sourceware.org/bugzilla/show_bug.cgi?id=22263

Also TLS code sequence in SH assembly syscalls in glibc doesn't match TLS
code sequence expected by ld:

https://sourceware.org/bugzilla/show_bug.cgi?id=22270

FAIL: glibcs-sparc64-linux-gnu build
FAIL: glibcs-sparcv9-linux-gnu build
FAIL: glibcs-tilegxbe-linux-gnu build
FAIL: glibcs-tilegxbe-linux-gnu-32 build
FAIL: glibcs-tilegx-linux-gnu build
FAIL: glibcs-tilegx-linux-gnu-32 build
FAIL: glibcs-tilepro-linux-gnu build

elf/sln is failed to link due to:

ld: read-only segment has dynamic relocations.

This is caused by linker bug and/or non-PIC code in PIE libc.a.  See:

https://sourceware.org/bugzilla/show_bug.cgi?id=22263

	[BZ #19574]
	* INSTALL: Regenerated.
	* Makeconfig (real-static-start-installed-name): New.
	(pic-default): Updated for --enable-static-pie.
	(pie-default): New for --enable-static-pie.
	(default-pie-ldflag): Likewise.
	(+link-static-before-libc): Replace $(DEFAULT-LDFLAGS-$(@F))
	with $(if $($(@F)-no-pie),$(no-pie-ldflag),$(default-pie-ldflag)).
	Replace $(static-start-installed-name) with
	$(real-static-start-installed-name).
	(+prectorT): Updated for --enable-static-pie.
	(+postctorT): Likewise.
	(CFLAGS-.o): Add $(pie-default).
	(CFLAGS-.op): Likewise.
	* NEWS: Mention --enable-static-pie.
	* config.h.in (ENABLE_STATIC_PIE): New.
	* configure.ac (--enable-static-pie): New configure option.
	(have-no-dynamic-linker): New LIBC_CONFIG_VAR.
	(have-static-pie): Likewise.
	Enable static PIE if linker supports --no-dynamic-linker.
	(ENABLE_STATIC_PIE): New AC_DEFINE.
	(enable-static-pie): New LIBC_CONFIG_VAR.
	* configure: Regenerated.
	* csu/Makefile (omit-deps): Add r$(start-installed-name) and
	gr$(start-installed-name) for --enable-static-pie.
	(extra-objs): Likewise.
	(install-lib): Likewise.
	(extra-objs): Add static-reloc.o and static-reloc.os
	($(objpfx)$(start-installed-name)): Also depend on
	$(objpfx)static-reloc.o.
	($(objpfx)r$(start-installed-name)): New.
	($(objpfx)g$(start-installed-name)): Also depend on
	$(objpfx)static-reloc.os.
	($(objpfx)gr$(start-installed-name)): New.
	* csu/libc-start.c (LIBC_START_MAIN): Call _dl_relocate_static_pie
	in libc.a.
	* csu/libc-tls.c (__libc_setup_tls): Add main_map->l_addr to
	initimage.
	* csu/static-reloc.c: New file.
	* elf/Makefile (routines): Add dl-reloc-static-pie.
	(elide-routines.os): Likewise.
	(DEFAULT-LDFLAGS-tst-tls1-static-non-pie): Removed.
	(tst-tls1-static-non-pie-no-pie): New.
	* elf/dl-reloc-static-pie.c: New file.
	* elf/dl-support.c (_dl_get_dl_main_map): New function.
	* elf/dynamic-link.h (ELF_DURING_STARTUP): Also check
	STATIC_PIE_BOOTSTRAP.
	* elf/get-dynamic-info.h (elf_get_dynamic_info): Likewise.
	* gmon/Makefile (tests): Add tst-gmon-static-pie.
	(tests-static): Likewise.
	(DEFAULT-LDFLAGS-tst-gmon-static): Removed.
	(tst-gmon-static-no-pie): New.
	(CFLAGS-tst-gmon-static-pie.c): Likewise.
	(CRT-tst-gmon-static-pie): Likewise.
	(tst-gmon-static-pie-ENV): Likewise.
	(tests-special): Likewise.
	($(objpfx)tst-gmon-static-pie.out): Likewise.
	(clean-tst-gmon-static-pie-data): Likewise.
	($(objpfx)tst-gmon-static-pie-gprof.out): Likewise.
	* gmon/tst-gmon-static-pie.c: New file.
	* manual/install.texi: Document --enable-static-pie.
	* sysdeps/generic/ldsodefs.h (_dl_relocate_static_pie): New.
	(_dl_get_dl_main_map): Likewise.
	* sysdeps/i386/configure.ac: Check if linker supports static PIE.
	* sysdeps/x86_64/configure.ac: Likewise.
	* sysdeps/i386/configure: Regenerated.
	* sysdeps/x86_64/configure: Likewise.
	* sysdeps/mips/Makefile (ASFLAGS-.o): Add $(pie-default).
	(ASFLAGS-.op): Likewise.
2017-12-15 17:12:14 -08:00
Joseph Myers
8df5d34720 Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.

For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing.  For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.

We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.

This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler.  Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.

The config.make with-fp variable remains.  It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables.  For powerpc, -mcpu= options can imply use of
soft-float.  That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory.  If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).

Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.

	* configure.ac (--with-fp): Remove configure option.
	(with_fp_cond): New variable.
	(libc_cv_with_fp): New configure test.  Use this variable instead
	of with_fp.
	* configure: Regenerated.
	* config.make.in (with-fp): Use @libc_cv_with_fp@.
	* manual/install.texi (Configuring and compiling): Remove
	--without-fp.
	* INSTALL: Regenerated.
	* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
	* sysdeps/mips/preconfigure (with_fp_cond): Define.
	* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
	* sysdeps/sh/preconfigure (with_fp_cond): Define.
	* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
	use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
Rogerio Alves
07ed18d26a Add elision tunables
This patch adds several new tunables to control the behavior of
elision on supported platforms[1].   Since elision now depends
on tunables, we should always *compile* with elision enabled,
and leave the code disabled, but available for runtime
selection.  This gives us *much* better compile-time testing of
the existing code to avoid bit-rot[2].

Tested on ppc, ppc64, ppc64le, s390x and x86_64.

[1] This part of the patch was initially proposed by
Paul Murphy but was "staled" because the framework have changed
since the patch was originally proposed:

https://patchwork.sourceware.org/patch/10342/

[2] This part of the patch was inititally proposed as a RFC by
Carlos O'Donnell.  Make sense to me integrate this on the patch:

https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html

	* elf/dl-tunables.list: Add elision parameters.
	* manual/tunables.texi: Add entries about elision tunable.
	* sysdeps/unix/sysv/linux/powerpc/elision-conf.c:
	Add callback functions to dynamically enable/disable elision.
	Add multiple callbacks functions to set elision parameters.
	Deleted __libc_enable_secure check.
	* sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise.
	* sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise.
	* configure: Regenerated.
	* configure.ac: Option enable_lock_elision was deleted.
	* config.h.in: ENABLE_LOCK_ELISION flag was deleted.
	* config.make.in: Remove references to enable_lock_elision.
	* manual/install.texi: Elision configure option was removed.
	* INSTALL: Regenerated to remove enable_lock_elision.
	* nptl/Makefile:
	Disable elision so it can verify error case for destroying a mutex.
	* sysdeps/powerpc/nptl/elide.h:
	Cleanup ENABLE_LOCK_ELISION check.
	Deleted macros for the case when ENABLE_LOCK_ELISION was not defined.
	* sysdeps/s390/configure: Regenerated.
	* sysdeps/s390/configure.ac: Remove references to enable_lock_elision..
	* nptl/tst-mutex8.c:
	Deleted all #ifndef ENABLE_LOCK_ELISION from the test.
	* sysdeps/powerpc/powerpc32/sysdep.h:
	Deleted all ENABLE_LOCK_ELISION checks.
	* sysdeps/powerpc/powerpc64/sysdep.h: Likewise.
	* sysdeps/powerpc/sysdep.h: Likewise.
	* sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise.
	* sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise.
	* sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise.
	* sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise.
	* sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise.
	* sysdeps/unix/sysv/linux/s390/Makefile: Remove references to
	enable-lock-elision.

Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 17:48:48 -02:00
Juro Bystricky
1faaf7035c plural.c: improve reproducibility
There is a subtle non-determinism when building glibc.
This depends on whether the glibc is built using the distibuted
file intl/plural.c or built using the generated file intl/plural.c.
These two files (intl/plural.c generated vs. distributed) are slightly
different, hence we may end up with slightly different libraries.

Originally, having "bison" installed was optional. So if "bison" was
not present, we always built libraries with the distributed plural.c.
If bison was installed, we *** may have *** replaced the distributed
file plural.c with a new plural.c generated from plural.y. if the
timestamps triggered this rule:

plural.c plural.y
	$(BISON) $(BISONFLAGS) $@ $^

Given that timestamps are not preserved in GIT repositories, the above
rule is not reliable without explicitly touching plural.c or plural.y.
In other words, the rule may or may not have fired.

In summary: there are two distinct sources of non-determinism:

1. Having "bison" installed or not
2. Having "bison" installed but timestamps poorly defined.

This patch fixes this by requiring "bison" being installed
and by always generating intl/plural.c from intl/plural.y.
(This is achieved by simply removing checked-in intl/plural.c)

	[BZ #22432]
	* configure.ac (BISON): Require to be present.
	* configure: Regenerated.
	* intl/Makefile (generated): Add plural.c.
	[$(BISON) != no]: Make code unconditional.
	(plural.c): Change rule to $(objpfx)plural.c.
	($(objpfx)plural.o): Depend on $(objpfx)plural.c.
	* intl/plural.c: Remove.
	* manual/install.texi (Tools for Compilation): Document bison as
	required.
	* INSTALL: Regenerated.
2017-11-30 21:21:15 +00:00
Siddhesh Poyarekar
7b0fb8706c Fix botched up regeneration in the last commit 2017-11-16 12:08:52 +05:30
Siddhesh Poyarekar
a306c790a8 Prefer https for Sourceware links
Update all sourceware links to https.  The website redirects
everything to https anyway so let the web server do a bit less work.
The only reference that remains unchanged is the one in the old
ChangeLog, since it didn't seem worth changing it.

	* NEWS: Update sourceware link to https.
	* configure.ac: Likewise.
	* crypt/md5test-giant.c: Likewise.
	* dlfcn/bug-atexit1.c: Likewise.
	* dlfcn/bug-atexit2.c: Likewise.
	* localedata/README: Likewise.
	* malloc/tst-mallocfork.c: Likewise.
	* manual/install.texi: Likewise.
	* nptl/tst-pthread-getattr.c: Likewise.
	* stdio-common/tst-fgets.c: Likewise.
	* stdio-common/tst-fwrite.c: Likewise.
	* sunrpc/Makefile: Likewise.
	* sysdeps/arm/armv7/multiarch/memcpy_impl.S: Likewise.
	* wcsmbs/tst-mbrtowc2.c: Likewise.
	* configure: Regenerate.
	* INSTALL: Regenerate.
2017-11-16 11:49:26 +05:30
Joseph Myers
644d38570a Remove add-ons mechanism.
glibc has an add-ons mechanism to allow additional software to be
integrated into the glibc build.  Such add-ons may be within the glibc
source tree, or outside it at a path passed to the --enable-add-ons
configure option.

localedata and crypt were once add-ons, distributed in separate
release tarballs, but long since stopped using that mechanism.
Linuxthreads was always an add-on.  Ports spent some time as an add-on
with separate release tarballs, then was first moved into the glibc
source tree, then had its sysdeps files moved into the main sysdeps
hierarchy so the add-ons mechanism was no longer used.  NPTL spent
some time as an add-on in the main glibc tree before stopping using
the add-on mechanism.  libidn used to have separate release tarballs
but no longer does so, but still uses the add-ons mechanism within the
glibc source tree.  Various other software has supported building with
the add-ons mechanism at times in the past, but I don't think any is
still widely used.

Add-ons involve significant, little-used complexity in the glibc build
system, and make it hard to understand what the space of possible
glibc configurations is.  This patch removes the add-ons mechanism.
libidn is now built via the Subdirs mechanism to cause any
configuration using sysdeps/unix/inet to build libidn; HAVE_LIBIDN
(which effectively means shared libraries are available) is now
defined via sysdeps/unix/inet/configure.  Various references to
add-ons around the source tree are removed (in the case of maint.texi,
the example list of sysdeps directories is still very out of date).

Externally maintained ports should now put their files in the normal
sysdeps directory structure rather than being arranged as add-ons;
they probably need to change e.g. elf.h anyway, rather than actually
being able to work just as a drop-in subtree.  Hurd libpthread should
be arranged similarly to NPTL, so some files might go in a
hurd-pthreads (or similar) top-level directory in glibc, while sysdeps
files should go in the normal sysdeps directory structure (possibly in
hurd or hurd-pthreads subdirectories, just as there are nptl
subdirectories in the sysdeps tree).

Tested for x86_64, and with build-many-glibcs.py.

	* configure.ac (--enable-add-ons): Remove option.
	(machine): Do not mention add-ons in comment.
	(LIBC_PRECONFIGURE): Likewise.
	(add_ons): Remove variable and sanity checks and logic to locate
	add-ons.
	(add_ons_automatic): Remove variable.
	(configured_add_ons): Likewise.
	(add_ons_sfx): Likewise.
	(add_ons_pfx): Likewise.
	(add_on_subdirs): Likewise.
	(sysnames_add_ons): Likewise.  Remove loop over add-ons and
	consideration of add-ons in Implies handling.
	(sysdeps_add_ons): Likewise.
	* configure: Regenerated.
	* libidn/configure.ac: Remove.
	* libidn/configure: Likewise.
	* sysdeps/unix/inet/configure.ac: New file.
	* sysdeps/unix/inet/configure: New generated file.
	* sysdeps/unix/inet/Subdirs: Add libidn.
	* Makeconfig (sysdeps-srcdirs): Remove variable.
	(+sysdep_dirs): Do not include $(sysdeps-srcdirs).
	($(common-objpfx)config.status): Do not depend on add-on files.
	($(common-objpfx)shlib-versions.v.i): Do not mention add-ons in
	comment.
	(all-subdirs): Do not include $(add-on-subdirs).
	* Makefile (dist-prepare): Do not use $(sysdeps-add-ons).
	* config.make.in (add-ons): Remove variable.
	(add-on-subdirs): Likewise.
	(sysdeps-add-ons): Likewise.
	* manual/Makefile (add-chapters): Remove.
	($(objpfx)texis): Do not depend on $(add-chapters).
	(nonexamples): Do not handle $(add-chapters).
	(examples): Do not handle $(add-ons).
	(chapters.% top-menu.%): Do not pass '$(add-chapters)' to
	libc-texinfo.sh.
	* manual/install.texi (Installation): Do not mention add-ons.
	(--enable-add-ons): Do not document configure option.
	* INSTALL: Regenerated.
	* manual/libc-texinfo.sh: Do not handle $2 add-ons argument.
	* manual/maint.texi (Hierarchy Conventions): Do not mention
	add-ons.
	* scripts/build-many-glibcs.py (Glibc.build_glibc): Do not use
	--enable-add-ons.
	* scripts/gen-sorted.awk: Do not handle Subdirs files from
	add-ons.
	* scripts/test-installation.pl: Do not handle glibc-compat add-on.
	* sysdeps/nptl/Makeconfig: Do not mention add-ons in comment.
2017-10-05 15:58:13 +00:00
Siddhesh Poyarekar
15192aaa25 Update contributors and latest gcc and binutils versions 2017-08-02 18:22:58 +05:30
DJ Delorie
d5c3fafc43 Add per-thread cache to malloc
* config.make.in: Enable experimental malloc option.
* configure.ac: Likewise.
* configure: Regenerate.
* manual/install.texi: Document it.
* INSTALL: Regenerate.
* malloc/Makefile: Likewise.
* malloc/malloc.c: Add per-thread cache (tcache).
(tcache_put): New.
(tcache_get): New.
(tcache_thread_freeres): New.
(tcache_init): New.
(__libc_malloc): Use cached chunks if available.
(__libc_free): Initialize tcache if needed.
(__libc_realloc): Likewise.
(__libc_calloc): Likewise.
(_int_malloc): Prefill tcache when appropriate.
(_int_free): Likewise.
(do_set_tcache_max): New.
(do_set_tcache_count): New.
(do_set_tcache_unsorted_limit): New.
* manual/probes.texi: Document new probes.
* malloc/arena.c: Add new tcache tunables.
* elf/dl-tunables.list: Likewise.
* manual/tunables.texi: Document them.
* NEWS: Mention the per-thread cache.
2017-07-06 13:37:30 -04:00
Joseph Myers
073e8fa773 Require binutils 2.25 or later to build glibc.
This patch implements a requirement of binutils >= 2.25 (up from 2.22)
to build glibc.  Tests for 2.24 or later on x86_64 and s390 are
removed.  It was already the case, as indicated by buildbot results,
that 2.24 was too old for building tests for 32-bit x86 (produced
internal linker errors linking elf/tst-gnu2-tls1mod.so).  I don't know
if any configure tests for binutils features are obsolete given the
increased version requirement.

Tested for x86_64.

	* configure.ac (AS): Require binutils 2.25 or later.
	(LD): Likewise.
	* configure: Regenerated.
	* sysdeps/s390/configure.ac (AS): Remove version check.
	* sysdeps/s390/configure: Regenerated.
	* sysdeps/x86_64/configure.ac (AS): Remove version check.
	* sysdeps/x86_64/configure: Regenerated.
	* manual/install.texi (Tools for Compilation): Document
	requirement for binutils 2.25 or later.
	* INSTALL: Regenerated.
2017-06-28 11:31:50 +00:00
Gabriel F. T. Gomes
4efe3ce400 powerpc64le: Check for compiler features for float128
On powerpc64le, support for float128 will be enabled, which requires some
compiler features to be present.  This patch adds a configure test to check
for such features, which are provided for powerpc64le since GCC 6.2.

Tested for powerpc64 and powerpc64le.

	* INSTALL: Regenerate.
	* manual/install.texi (Recommended Tools for Compilation): Mention
	the powerpc64le-specific requirement in the manual.
	* sysdeps/powerpc/powerpc64le/configure.ac: New file with checks
	for the compiler features required for building float128.
	* sysdeps/powerpc/powerpc64le/configure: New, auto-generated file.
2017-06-26 14:58:47 -03:00
Joseph Myers
4add86749a Require GCC 4.9 or later for building glibc.
This patch makes configure require GCC 4.9 or later for building
glibc, and documents that requirement.  Requiring GCC 4.9 or later
allows use of _Generic (as in tzcode).  It would allow <stdatomic.h>
and _Atomic to be used as well if desired, although we need to avoid
any libatomic dependencies on any platforms.  This patch is explicitly
the minimum to implement a new version requirement, with any
consequent cleanups of conditional code (not in installed headers or
files shared with gnulib etc.) to be done separately.

Tested for x86_64.

	* configure.ac (libc_cv_compiler_ok): Require GCC 4.9 or later.
	* configure: Regenerated.
	* manual/install.texi (Tools for Compilation): Document
	requirement for GCC 4.9 or later.
	* INSTALL: Regenerated.
2017-06-19 16:34:05 +00:00
Siddhesh Poyarekar
2c0b90ab44 Enable tunables by default
All of the major architectures are adopting tunables as a way to add
tuning to the library, from hwcap_mask for aarch64 to HLE for s390 and
ifunc and cache geometry for x86.  Given this adoption and the fact
that we don't want additional tuning knobs to be added outside of
tunables, it makes sense to enable tunables by default using this
trivial patch.

Smoke tested on x86 to ensure that tunables code was built without
specifying it as a configure flag.  I have kept it as --enabled and
not changed it to --disable since we want to still keep the option of
different kinds of front-ends for tunables.

	* configure.ac(--enable-tunables): Enable by default.
	* configure: Regenerate.
	* NEWS: Mention change.
	* manual/install.texi (enable-tunables): Adjust documentation.
	* INSTALL: Regenerate.
2017-06-15 15:12:54 +05:30
Florian Weimer
e92030239a Assume that accept4 is always available and works
Simplify the Linux accept4 implementation based on the assumption
that it is available in some way.  __ASSUME_ACCEPT4_SOCKETCALL was
previously unused, so remove it.

For ia64, the accept4 system call (and socket call) were backported
in kernel version 3.2.18.  Reflect this in the installation
instructions.
2017-04-19 07:44:48 +02:00
Joseph Myers
a640393a18 Regenerate INSTALL. 2017-03-21 16:40:16 +00:00
Florian Weimer
2d6ab5df3b Document and fix --enable-bind-now [BZ #21015] 2017-03-02 14:44:28 +01:00
Joseph Myers
ae7b8fbdda Update install.texi latest GCC version known to work.
* manual/install.texi (Tools for Compilation): Update GCC version
	known to work to build glibc.
	* INSTALL: Regenerated.
2017-01-18 17:27:47 +00:00
Siddhesh Poyarekar
6765d5d34d Enhance --enable-tunables to select tunables frontend at build time
At the GNU Tools Cauldron 2016, the state of the current tunables
patchset was considered OK with the addition of a way to select the
frontend to be used for the tunables.  That is, to avoid being locked
in to one type of frontend initially, it should be possible to build
tunables with a different frontend with something as simple as a
configure switch.

To that effect, this patch enhances the --enable-tunables option to
accept more values than just 'yes' or 'no'.  The current frontend (and
default when enable-tunables is 'yes') is called 'valstring', to
select the frontend where a single environment variable is set to a
colon-separated value string.  More such frontends can be added in
future.

	* Makeconfig (have-tunables): Check for non-negative instead
	of positive.
	* configure.ac: Add 'valstring' as a valid value for
	--enable-tunables.
	* configure: Regenerate.
	* elf/Makefile (have-tunables): Check for non-negative instead
	of positive.
	(CPPFLAGS-dl-tunables.c): Define TUNABLES_FRONTEND for
	dl-tunables.c.
	* elf/dl-tunables.c (GLIBC_TUNABLES): Define only when
	TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring.
	(tunables_strdup): Likewise.
	(disable_tunables): Likewise.
	(parse_tunables): Likewise.
	(__tunables_init): Process GLIBC_TUNABLES envvar only when.
	TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring.
	* elf/dl-tunables.h (TUNABLES_FRONTEND_valstring): New macro.
	(TUNABLES_FRONTEND_yes): New macro, define as
	TUNABLES_FRONTEND_valstring by default.
	* manual/install.texi: Document new acceptable values for
	--enable-tunables.
	* INSTALL: Regenerate.
2016-12-31 23:49:24 +05:30
Siddhesh Poyarekar
67e58f3941 Add framework for tunables
The tunables framework allows us to uniformly manage and expose global
variables inside glibc as switches to users.  tunables/README has
instructions for glibc developers to add new tunables.

Tunables support can be enabled by passing the --enable-tunables
configure flag to the configure script.  This patch only adds a
framework and does not pose any limitations on how tunable values are
read from the user.  It also adds environment variables used in malloc
behaviour tweaking to the tunables framework as a PoC of the
compatibility interface.

	* manual/install.texi: Add --enable-tunables option.
	* INSTALL: Regenerate.
	* README.tunables: New file.
	* Makeconfig (CPPFLAGS): Define TOP_NAMESPACE.
	(before-compile): Generate dl-tunable-list.h early.
	* config.h.in: Add HAVE_TUNABLES.
	* config.make.in: Add have-tunables.
	* configure.ac: Add --enable-tunables option.
	* configure: Regenerate.
	* csu/init-first.c (__libc_init_first): Move
	__libc_init_secure earlier...
	* csu/init-first.c (LIBC_START_MAIN):... to here.
	Include dl-tunables.h, libc-internal.h.
	(LIBC_START_MAIN) [!SHARED]: Initialize tunables for static
	binaries.
	* elf/Makefile (dl-routines): Add dl-tunables.
	* elf/Versions (ld): Add __tunable_set_val to GLIBC_PRIVATE
	namespace.
	* elf/dl-support (_dl_nondynamic_init): Unset MALLOC_CHECK_
	only when !HAVE_TUNABLES.
	* elf/rtld.c (process_envvars): Likewise.
	* elf/dl-sysdep.c [HAVE_TUNABLES]: Include dl-tunables.h
	(_dl_sysdep_start): Call __tunables_init.
	* elf/dl-tunable-types.h: New file.
	* elf/dl-tunables.c: New file.
	* elf/dl-tunables.h: New file.
	* elf/dl-tunables.list: New file.
	* malloc/tst-malloc-usable-static.c: New test case.
	* malloc/Makefile (tests-static): Add it.
	* malloc/arena.c [HAVE_TUNABLES]: Include dl-tunables.h.
	Define TUNABLE_NAMESPACE.
	(DL_TUNABLE_CALLBACK (set_mallopt_check)): New function.
	(DL_TUNABLE_CALLBACK_FNDECL): New macro.  Use it to define
	callback functions.
	(ptmalloc_init): Set tunable values.
	* scripts/gen-tunables.awk: New file.
	* sysdeps/mach/hurd/dl-sysdep.c: Include dl-tunables.h.
	(_dl_sysdep_start): Call __tunables_init.
2016-12-31 23:49:24 +05:30
Nick Alcock
03baef1c9c Configure support for --enable-stack-protector [BZ #7065]
This adds =all and =strong, with obvious semantics, defaulting to off.

We don't validate the value of the option yet: that's in a later patch.
Nor do we use it for anything at this stage.

We differentiate between 'the compiler understands -fstack-protector'
and 'the user wanted -fstack-protector' so that we can pass
-fno-stack-protector in appropriate places even if the user didn't want
to turn on -fstack-protector for other parts.  (This helps us overcome
another existing limitation, that glibc doesn't work with GCCs hacked
to pass in -fstack-protector by default.)

We also arrange to set the STACK_PROTECTOR_LEVEL #define to a value
appropriate for the stack-protection level in use for each file in
particular.
2016-12-26 10:08:19 +01:00
Martin Galvan
23b5cae1af Add pretty printers for the NPTL lock types
This patch adds pretty printers for the following NPTL types:

- pthread_mutex_t
- pthread_mutexattr_t
- pthread_cond_t
- pthread_condattr_t
- pthread_rwlock_t
- pthread_rwlockattr_t

To load the pretty printers into your gdb session, do the following:

python
import sys
sys.path.insert(0, '/path/to/glibc/build/nptl/pretty-printers')
end

source /path/to/glibc/source/pretty-printers/nptl-printers.py

You can check which printers are registered and enabled by issuing the
'info pretty-printer' gdb command. Printers should trigger automatically when
trying to print a variable of one of the types mentioned above.

The printers are architecture-independent, and were tested on an AMD64 running
Ubuntu 14.04 and an x86 VM running Fedora 24.

In order to work, the printers need to know the values of various flags that
are scattered throughout pthread.h and pthreadP.h as enums and #defines. Since
replicating these constants in the printers file itself would create a
maintenance burden, I wrote a script called gen-py-const.awk that Makerules uses
to extract the constants. This script is pretty much the same as gen-as-const.awk,
except it doesn't cast the constant values to 'long' and is thorougly documented.
The constants need only to be enumerated in a .pysym file, which is then referenced
by a Make variable called gen-py-const-headers.

As for the install directory, I discussed this with Mike Frysinger and Siddhesh
Poyarekar, and we agreed that it can be handled in a separate patch, and shouldn't
block merging of this one.

In addition, I've written a series of test cases for the pretty printers.
Each lock type (mutex, condvar and rwlock) has two test programs, one for itself
and other for its related 'attributes' object. Each test program in turn has a
PExpect-based Python script that drives gdb and compares its output to the
expected printer's. The tests run on the glibc host, which is assumed to have
both gdb and PExpect; if either is absent the tests will fail with code 77
(UNSUPPORTED). For cross-testing you should use cross-test-ssh.sh as test-wrapper.
I've tested the printers on both native builds and a cross build using a Beaglebone
Black running Debian, with the build system's filesystem shared with the board
through NFS.

Finally, I've written a README that explains all this and more.

	* INSTALL: Regenerated.
	* Makeconfig: Add comments and whitespace to make the control flow
	clearer.
	(+link-printers-tests, +link-pie-printers-tests, CFLAGS-printers-tests,
	installed-rtld-LDFLAGS, built-rtld-LDFLAGS, link-libc-rpath,
	link-libc-tests-after-rpath-link, link-libc-printers-tests): New.
	(rtld-LDFLAGS, rtld-tests-LDFLAGS, link-libc-tests-rpath-link,
	link-libc-tests): Use the new variables as required.
	* Makerules ($(py-const)): New rule.
	generated: Add $(py-const).
	* README.pretty-printers: New file.
	* Rules (tests-printers-programs, tests-printers-out, py-env): New.
	(others): Depend on $(py-const).
	(tests): Depend on $(tests-printers-programs) or $(tests-printers-out),
	as required.  Pass $(tests-printers) to merge-test-results.sh.
	* manual/install.texi: Add requirements for testing the pretty printers.
	* nptl/Makefile (gen-py-const-headers, pretty-printers, tests-printers,
	CFLAGS-test-mutexattr-printers.c CFLAGS-test-mutex-printers.c,
	CFLAGS-test-condattr-printers.c, CFLAGS-test-cond-printers.c,
	CFLAGS-test-rwlockattr-printers.c CFLAGS-test-rwlock-printers.c,
	tests-printers-libs): Define.
	* nptl/nptl-printers.py: New file.
	* nptl/nptl_lock_constants.pysym: Likewise.
	* nptl/test-cond-printers.c: Likewise.
	* nptl/test-cond-printers.py: Likewise.
	* nptl/test-condattr-printers.c: Likewise.
	* nptl/test-condattr-printers.py: Likewise.
	* nptl/test-mutex-printers.c: Likewise.
	* nptl/test-mutex-printers.py: Likewise.
	* nptl/test-mutexattr-printers.c: Likewise.
	* nptl/test-mutexattr-printers.py: Likewise.
	* nptl/test-rwlock-printers.c: Likewise.
	* nptl/test-rwlock-printers.py: Likewise.
	* nptl/test-rwlockattr-printers.c: Likewise.
	* nptl/test-rwlockattr-printers.py: Likewise.
	* scripts/gen-py-const.awk: Likewise.
	* scripts/test_printers_common.py: Likewise.
	* scripts/test_printers_exceptions.py: Likewise.
2016-12-08 18:59:02 +05:30
Stefan Liebler
022dfdce00 Add configure check to test if gcc supports attribute ifunc.
This patch adds a configure check to test if gcc supports attribute ifunc.
The support can either be enabled in <gcc-src>/gcc/config.gcc for one
architecture in general by setting default_gnu_indirect_function variable to yes
or by configuring gcc with --enable-gnu-indirect-function.

The next patch rewrites libc_ifunc macro to use gcc attribute ifunc instead
of inline assembly to generate the IFUNC symbols due to false debuginfo.

If gcc does not support attribute ifunc, the old approach for generating
ifunc'ed symbols is used. Then the debug-information is false. Thus it is
recommended to use a gcc with indirect function support (See notes in INSTALL).
After this patch-series these inline assemblies for ifunc-handling are not
scattered in multiple files but are used only indirect via ifunc-macros
and can simply removed in libc-symbols.h in future.

If glibc is configured with --enable-multi-arch and gcc does not support
attribute ifunc, a configure warning is dumped!

ChangeLog:

	* config.h.in (HAVE_GCC_IFUNC): New undef.
	* configure.ac: Add check if gcc supports attribute ifunc feature.
	* configure: Regenerated.
	* manual/install.texi: Add recommendation for gcc with
	indirect-function support.
	* INSTALL: Regenerated.
2016-10-07 10:02:59 +02:00
Rical Jasan
b55a155f00 Manual typos: Installing
2016-05-06  Rical Jasan  <ricaljasan@pacific.net>

	* manual/install.texi: Fix typos in the manual.
	* INSTALL: Regenerated.
2016-10-06 12:28:45 +05:30
Paul Pluzhnikov
b9f5c3acc0 2016-06-05 Paul Pluzhnikov <ppluzhnikov@google.com>
* manual/install.texi: Remove mention of --without-tls
	* INSTALL: Regenerate.
2016-06-05 08:41:13 -07:00
Joseph Myers
5b4ecd3f95 Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere.
In <https://sourceware.org/ml/libc-alpha/2016-01/msg00885.html> I
proposed a minimum Linux kernel version of 3.2 for glibc 2.24, since
Linux 2.6.32 has reached EOL.

In the discussion in February, some concerns were expressed about
compatibility with OpenVZ containers.  It's not clear that these are
real issues, given OpenVZ backporting kernel features and faking the
kernel version for guest software, as discussed in
<https://sourceware.org/ml/libc-alpha/2016-02/msg00278.html>.  It's
also not clear that supporting running GNU/Linux distributions from
late 2016 (at the earliest) on a kernel series from 2009 is a sensible
expectation.  However, as an interim step, this patch increases the
requirement everywhere except x86 / x86_64 (since the controversy was
only about those architectures); the special caveats and settings can
easily be removed later when we're ready to increase the requirements
on x86 / x86_64 (and if someone would like to raise the issue on LWN
as suggested in the previous discussion, that would be welcome).  3.2
kernel headers are required everywhere by this patch.

(x32 already requires 3.4 or later, so is unaffected by this patch.)

As usual for such a change, this patch only changes the configure
scripts and associated documentation.  The intent is to follow up with
removal of dead __LINUX_KERNEL_VERSION conditionals.  Each __ASSUME_*
or other macro that becomes dead can then be removed independently.

Tested for x86_64 and x86.

	* sysdeps/unix/sysv/linux/configure.ac (LIBC_LINUX_VERSION):
	Define to 3.2.0.
	(arch_minimum_kernel): Likewise.
	* sysdeps/unix/sysv/linux/configure: Regenerated.
	* sysdeps/unix/sysv/linux/i386/configure.ac (arch_minimum_kernel):
	Define to 2.6.32.
	* sysdeps/unix/sysv/linux/i386/configure: Regenerated.
	* sysdeps/unix/sysv/linux/x86_64/64/configure.ac
	(arch_minimum_kernel): Define to 2.6.32.
	* sysdeps/unix/sysv/linux/x86_64/64/configure: Regenerated.
	* README: Document Linux 3.2 requirement.
	* manual/install.texi (Linux): Document Linux 3.2 headers
	requirement.
	* INSTALL: Regenerated.
2016-02-24 17:15:12 +00:00
Carlos O'Donell
2c8f75f79b Update INSTALL with latest versions tested to work. 2016-02-14 20:54:29 -05:00
Joseph Myers
b08b421835 Require GCC 4.7 or later to build glibc.
This patch implements a requirement of GCC 4.7 or later to build
glibc.

This was discussed in the thread starting at
<https://sourceware.org/ml/libc-alpha/2015-08/msg00851.html>.
Concerns were expressed by Mike and David.  At
<https://sourceware.org/ml/libc-alpha/2015-10/msg00453.html> I have
provided a 14-patch series showing in outline the cleanups facilitated
by this version requirement, as requested by Mike (this patch is the
first in that series, with the addition of a NEWS entry).  Given the
absence of further concerns or alternative proposals for criteria for
updates to this version requirement as requested in
<https://sourceware.org/ml/libc-alpha/2015-10/msg00065.html>, I am
interpreting this as "absence of sustained opposition" under Carlos's
definition at <https://sourceware.org/glibc/wiki/Consensus> and
proposing this patch for inclusion in glibc.  I'd like to remind
people testing with 4.6 that if they move to testing with GCC 5 then
it will probably be about four years before they need to update the
compiler they use to test glibc again.

Although on the principles of time-based updates I think a move to
requiring binutils 2.23 would be reasonable, I'm not currently aware
of any cleanups that would facilitate so am not proposing that at this
time (but would expect to propose a move to requiring binutils 2.24 in
a year's time, as that brings features such as AVX512 support that
should allow some conditionals to be cleaned up).  If someone thinks a
move to requiring 2.23 would help clean things up for their
architecture, please speak up.  (And in general, I suspect there are
lots of architecture-specific configure tests that could be removed on
the basis of current GCC and binutils version requirements, given how
I've found architecture-independent tests obsolete on the basis of
version requirements going back 20 years.)

Tested for x86_64 and x86 (testsuite, and that installed shared
libraries are unchanged by the patch).

	* configure.ac (libc_cv_compiler_ok): Require GCC 4.7 or later.
	* configure: Regenerated.
	* manual/install.texi (Tools for Compilation): Document
	requirement for GCC 4.7 or later.
	* INSTALL: Regenerated.
2015-10-27 16:34:12 +00:00
Mike Frysinger
44f826e317 timezone: polish grammar a bit in documentation
Reported-by: ricaljasan@pacific.net
2015-10-19 14:12:03 -04:00
Mike Frysinger
1cba4036b6 timezone: add a configure flag to disable program install
Some distros build+install the timezone tools (zic/zdump/tzselect) outside
of glibc and use the upstream package directly.  Add a configure flag to
glibc so they can disable install of those tools.

This allows tests to run & pass regardless of the configure flag.  Only
the install of them is impacted.
2015-09-18 19:39:46 -04:00
Martin Sebor
a82a3db950 Attempting to install glibc configured with --prefix=/usr into
a non-standard directory specified by the prefix make variable
fails with an error.  Since this is an unsupported use case,
this change makes make install fail early and with a descriptive
error message when either the prefix or the exec_prefix make
variable is overridden on the command line.
2015-06-12 13:15:57 -06:00
Andrew Senkevich
2193311288 Start of series of patches with x86_64 vector math functions.
Here is implementation of cos containing SSE, AVX, AVX2 and AVX512
versions according to Vector ABI which had been discussed in
<https://groups.google.com/forum/#!topic/x86-64-abi/LmppCfN1rZ4>.

Vector math library build and ABI testing enabled by default for x86_64.

    * sysdeps/x86_64/fpu/Makefile: New file.
    * sysdeps/x86_64/fpu/Versions: New file.
    * sysdeps/x86_64/fpu/svml_d_cos_data.S: New file.
    * sysdeps/x86_64/fpu/svml_d_cos_data.h: New file.
    * sysdeps/x86_64/fpu/svml_d_cos2_core.S: New file.
    * sysdeps/x86_64/fpu/svml_d_cos4_core.S: New file.
    * sysdeps/x86_64/fpu/svml_d_cos4_core_avx.S: New file.
    * sysdeps/x86_64/fpu/svml_d_cos8_core.S: New file.
    * sysdeps/x86_64/fpu/svml_d_wrapper_impl.h: New file.
    * sysdeps/x86_64/fpu/multiarch/svml_d_cos2_core.S: New file.
    * sysdeps/x86_64/fpu/multiarch/svml_d_cos2_core_sse4.S: New file.
    * sysdeps/x86_64/fpu/multiarch/svml_d_cos4_core.S: New file.
    * sysdeps/x86_64/fpu/multiarch/svml_d_cos4_core_avx2.S: New file.
    * sysdeps/x86_64/fpu/multiarch/svml_d_cos8_core.S: New file.
    * sysdeps/x86_64/fpu/multiarch/svml_d_cos8_core_avx512.S: New file.
    * sysdeps/x86_64/fpu/multiarch/Makefile (libmvec-sysdep_routines): Added
    build of SSE, AVX2 and AVX512 IFUNC versions.
    * sysdeps/x86/fpu/bits/math-vector.h: Added SIMD declaration for cos.
    * math/bits/mathcalls.h: Added cos declaration with __MATHCALL_VEC.
    * sysdeps/x86_64/configure.ac: Options for libmvec build.
    * sysdeps/x86_64/configure: Regenerated.
    * sysdeps/x86_64/sysdep.h (cfi_offset_rel_rsp): New macro.
    * sysdeps/unix/sysv/linux/x86_64/libmvec.abilist: New file.
    * manual/install.texi (Configuring and compiling): Document
    --disable-mathvec.
    * INSTALL: Regenerated.
    * NEWS: Mention addition of libmvec and x86_64 vector cos.
2015-06-09 14:25:49 +03:00