<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc.git/scripts, branch zack/remove-libcrypt</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/'/>
<entry>
<title>Remove --enable-crypt and --enable-nss-crypt configure options.</title>
<updated>2023-09-21T20:21:41+00:00</updated>
<author>
<name>Zack Weinberg</name>
<email>zack@owlfolio.org</email>
</author>
<published>2023-09-21T15:22:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=a0b80d284cd22b88fc2da9a06cf81de8f2460e26'/>
<id>a0b80d284cd22b88fc2da9a06cf81de8f2460e26</id>
<content type='text'>
This makes it impossible to build libcrypt, so add a NEWS entry for
the removal at this point, and remove the prototype for crypt() from
unistd.h.  Also removed at this point are a handful of references to
libcrypt in other directories (notably elf/, conform/, and SPARCv9
sysdep Makefiles) and in maintainer-facing scripts and docs.

stdio-common/Versions says that __snprintf is exported as
GLIBC_PRIVATE because libcrypt uses it.  I doubt that was the only
ancillary library using that symbol, but I don't know how to find
other uses, so I left the export in place; it can always be removed
later.

There are a few files of test data that mention the crypt directory
and/or its contents, e.g. benchtests/strcoll-inputs/filelist#en_US.UTF-8.
As best I can tell, the intent of these is just to have a big pile of
strings and it doesn't matter whether the named files exist, so I
haven't altered them.

The actual code, and the remainder of the documentation, will be
deleted in subsequent patches.

(I seem to have a slightly different version of autoconf than the one
that was last used to regenerate the top-level configure script.  If
that's a problem, let me know.)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This makes it impossible to build libcrypt, so add a NEWS entry for
the removal at this point, and remove the prototype for crypt() from
unistd.h.  Also removed at this point are a handful of references to
libcrypt in other directories (notably elf/, conform/, and SPARCv9
sysdep Makefiles) and in maintainer-facing scripts and docs.

stdio-common/Versions says that __snprintf is exported as
GLIBC_PRIVATE because libcrypt uses it.  I doubt that was the only
ancillary library using that symbol, but I don't know how to find
other uses, so I left the export in place; it can always be removed
later.

There are a few files of test data that mention the crypt directory
and/or its contents, e.g. benchtests/strcoll-inputs/filelist#en_US.UTF-8.
As best I can tell, the intent of these is just to have a big pile of
strings and it doesn't matter whether the named files exist, so I
haven't altered them.

The actual code, and the remainder of the documentation, will be
deleted in subsequent patches.

(I seem to have a slightly different version of autoconf than the one
that was last used to regenerate the top-level configure script.  If
that's a problem, let me know.)
</pre>
</div>
</content>
</entry>
<entry>
<title>Use Linux 6.5 in build-many-glibcs.py</title>
<updated>2023-09-08T20:04:42+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>joseph@codesourcery.com</email>
</author>
<published>2023-09-08T20:04:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=deeaa5e90fcb45c7e58e4fd84d83bda46834680c'/>
<id>deeaa5e90fcb45c7e58e4fd84d83bda46834680c</id>
<content type='text'>
This patch makes build-many-glibcs.py use Linux 6.5.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch makes build-many-glibcs.py use Linux 6.5.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</pre>
</div>
</content>
</entry>
<entry>
<title>Use GMP 6.3.0, MPFR 4.2.1 in build-many-glibcs.py</title>
<updated>2023-08-29T14:11:35+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>joseph@codesourcery.com</email>
</author>
<published>2023-08-29T14:11:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=d3c34a2dd982a77abf631ea2f88f4efab1b064c4'/>
<id>d3c34a2dd982a77abf631ea2f88f4efab1b064c4</id>
<content type='text'>
This patch makes build-many-glibcs.py use the new GMP 6.3.0 and MPFR
4.2.1 releases.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch makes build-many-glibcs.py use the new GMP 6.3.0 and MPFR
4.2.1 releases.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</pre>
</div>
</content>
</entry>
<entry>
<title>Use binutils 2.41 branch in build-many-glibcs.py</title>
<updated>2023-08-08T12:53:50+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>joseph@codesourcery.com</email>
</author>
<published>2023-08-08T12:53:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=3fcfb76bab97e55e7491db5fc1f11655b0993865'/>
<id>3fcfb76bab97e55e7491db5fc1f11655b0993865</id>
<content type='text'>
This patch makes build-many-glibcs.py use binutils 2.41 branch.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch makes build-many-glibcs.py use binutils 2.41 branch.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</pre>
</div>
</content>
</entry>
<entry>
<title>scripts: Fix fortify checks if compiler does not support _FORTIFY_SOURCE=3</title>
<updated>2023-07-20T20:58:26+00:00</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2023-07-20T14:35:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=a3090c2c98facbab3d47aa23a94f8d2caeb78d71'/>
<id>a3090c2c98facbab3d47aa23a94f8d2caeb78d71</id>
<content type='text'>
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 &lt;siddhesh@sourceware.org&gt;
Tested-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;siddhesh@sourceware.org&gt;
Tested-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>configure: Disable building libcrypt by default</title>
<updated>2023-07-20T18:38:13+00:00</updated>
<author>
<name>Siddhesh Poyarekar</name>
<email>siddhesh@sourceware.org</email>
</author>
<published>2023-07-17T16:44:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=6c85c5a1773d786ccdc375e34431488fbcdd88e0'/>
<id>6c85c5a1773d786ccdc375e34431488fbcdd88e0</id>
<content type='text'>
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 &lt;siddhesh@sourceware.org&gt;
Reviewed-by: Andreas K. Hüttel &lt;dilfridge@gentoo.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;siddhesh@sourceware.org&gt;
Reviewed-by: Andreas K. Hüttel &lt;dilfridge@gentoo.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scripts: Add fortify checks on installed headers</title>
<updated>2023-07-19T19:06:24+00:00</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2023-07-19T14:37:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=30379efad117b85cc56a255cac628d0ad745bfe3'/>
<id>30379efad117b85cc56a255cac628d0ad745bfe3</id>
<content type='text'>
The _FORTIFY_SOURCE is used as default by some system compilers,
and there is no way to check if some fortify extension does not
trigger any conformance issue.

Checked on x86_64-linux-gnu.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The _FORTIFY_SOURCE is used as default by some system compilers,
and there is no way to check if some fortify extension does not
trigger any conformance issue.

Checked on x86_64-linux-gnu.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Allow glibc to be built with _FORTIFY_SOURCE</title>
<updated>2023-07-05T14:59:34+00:00</updated>
<author>
<name>Frédéric Bérat</name>
<email>fberat@redhat.com</email>
</author>
<published>2023-03-17T09:14:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=64d9580cdf7e417170abbef0327e04b29712e949'/>
<id>64d9580cdf7e417170abbef0327e04b29712e949</id>
<content type='text'>
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 &lt;siddhesh@sourceware.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;siddhesh@sourceware.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Use Linux 6.4 in build-many-glibcs.py</title>
<updated>2023-06-27T13:49:38+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>joseph@codesourcery.com</email>
</author>
<published>2023-06-27T13:49:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=aaa208502c97707119aea9e03a988bec26ad7817'/>
<id>aaa208502c97707119aea9e03a988bec26ad7817</id>
<content type='text'>
This patch makes build-many-glibcs.py use Linux 6.4.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch makes build-many-glibcs.py use Linux 6.4.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
</pre>
</div>
</content>
</entry>
<entry>
<title>Add lint-makefiles Makefile linting test.</title>
<updated>2023-06-03T01:43:05+00:00</updated>
<author>
<name>Carlos O'Donell</name>
<email>carlos@redhat.com</email>
</author>
<published>2023-05-18T20:18:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=547de57e5a54d3a02733523b75f261e95fc71579'/>
<id>547de57e5a54d3a02733523b75f261e95fc71579</id>
<content type='text'>
We add a 'make check' test that lints all Makefiles in the source
directory of the glibc build. This linting test ensures that the
lines in all Makefiles will be sorted correctly as developers
creates patches.  It is added to 'make check' because it is
light-weight and supports the existing developer workflow

The test adds ~3s to a 'make check' execution.

No regressions on x86_64 and i686.

Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We add a 'make check' test that lints all Makefiles in the source
directory of the glibc build. This linting test ensures that the
lines in all Makefiles will be sorted correctly as developers
creates patches.  It is added to 'make check' because it is
light-weight and supports the existing developer workflow

The test adds ~3s to a 'make check' execution.

No regressions on x86_64 and i686.

Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
