<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc/Makefile, branch master</title>
<subtitle>Fork of glibc for development</subtitle>
<id>https://git.zx2c4.com/glibc/atom/Makefile?h=master</id>
<link rel='self' href='https://git.zx2c4.com/glibc/atom/Makefile?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/'/>
<updated>2024-05-19T23:29:02Z</updated>
<entry>
<title>Pass -nostdlib -nostartfiles together with -r [BZ #31753]</title>
<updated>2024-05-19T23:29:02Z</updated>
<author>
<name>H.J. Lu</name>
<email>hjl.tools@gmail.com</email>
</author>
<published>2024-05-18T03:00:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=2be3352f0b1ebaa39596393fffe1062275186669'/>
<id>urn:sha1:2be3352f0b1ebaa39596393fffe1062275186669</id>
<content type='text'>
Since -r in GCC 6/7/8 doesn't imply -nostdlib -nostartfiles, update the
link-static-libc.out rule to also pass -nostdlib -nostartfiles.  This
fixes BZ #31753.

Signed-off-by: H.J. Lu &lt;hjl.tools@gmail.com&gt;
Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</content>
</entry>
<entry>
<title>Add a test to check for duplicate definitions in the static library</title>
<updated>2024-05-02T10:51:23Z</updated>
<author>
<name>Gabi Falk</name>
<email>gabifalk@gmx.com</email>
</author>
<published>2024-04-30T20:05:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=ded2e0753e9c46debeb2e0d26c5e560d2581d314'/>
<id>urn:sha1:ded2e0753e9c46debeb2e0d26c5e560d2581d314</id>
<content type='text'>
This change follows two previous fixes addressing multiple definitions
of __memcpy_chk and __mempcpy_chk functions on i586, and __memmove_chk
and __memset_chk functions on i686.  The test is intended to prevent
such issues from occurring in the future.

Signed-off-by: Gabi Falk &lt;gabifalk@gmx.com&gt;
Reviewed-by: H.J. Lu &lt;hjl.tools@gmail.com&gt;
Reviewed-by: Dmitry V. Levin &lt;ldv@altlinux.org&gt;
</content>
</entry>
<entry>
<title>Make sure INSTALL is ASCII plaintext again</title>
<updated>2024-04-30T07:54:07Z</updated>
<author>
<name>Mark Wielaard</name>
<email>mark@klomp.org</email>
</author>
<published>2024-04-28T14:59:39Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=ebfd73a80f15559fe59fee32a7844c6b8fa99576'/>
<id>urn:sha1:ebfd73a80f15559fe59fee32a7844c6b8fa99576</id>
<content type='text'>
This reverts commit 84e93afc7 ("Switch to UTF-8 for INSTALL") and
reinstates commit c14f2e4aa ("Make sure INSTALL is ASCII plaintext")
and regenerates INSTALL.

It turns out that different versions of makeinfo (texinfo/texi2any),
at least versions 7.0.3 and 7.1, put unicode quote glyphs in different
places (specifically whether contractions like you'd, don't, aren't or
you'll use ’ or '). This breaks the make dist target as used for
(snapshot) releases, which have a check on the regenerated INSTALL
file. Using --disable-encoding generates the same plaintext ASCII on
all versions.

An alternative would be to regenerate INSTALL with texinfo 7.1 and
require at least that version. But that seems too soon while various
distros don't have 7.1 yet. We can try again to use UTF-8 for INSTALL
in a couple of years.

Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</content>
</entry>
<entry>
<title>Update copyright dates with scripts/update-copyrights</title>
<updated>2024-01-01T18:53:40Z</updated>
<author>
<name>Paul Eggert</name>
<email>eggert@cs.ucla.edu</email>
</author>
<published>2024-01-01T18:12:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=dff8da6b3e89b986bb7f6b1ec18cf65d5972e307'/>
<id>urn:sha1:dff8da6b3e89b986bb7f6b1ec18cf65d5972e307</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Format test results closer to what DejaGnu does</title>
<updated>2023-11-03T12:58:17Z</updated>
<author>
<name>Maxim Kuvyrkov</name>
<email>maxim.kuvyrkov@linaro.org</email>
</author>
<published>2023-05-19T08:28:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=02976a4a4b2d01a524b33a508994664ffaf88d79'/>
<id>urn:sha1:02976a4a4b2d01a524b33a508994664ffaf88d79</id>
<content type='text'>
The years of dealing with Binutils, GCC and GDB test results
made the community create good tools for comparison and analysis
of DejaGnu test results.  This change allows to use those tools
for Glibc's test results as well.

The motivation for this change is Linaro's pre-commit testers,
which use a modified version of GCC's validate_failures.py
to create test xfail lists with baseline failures and known
flaky tests.  See below links for an example xfails file (only
one link is supposed to work at any given time):
- https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/lastSuccessfulBuild/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail/*view*/
- https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/lastSuccessfulBuild/artifact/artifacts/sumfiles/xfails.xfail/*view*/

Specifacally, this patch changes format of glibc's .sum files from ...
&lt;cut&gt;
FAIL: elf/test1
PASS: string/test2
&lt;/cut&gt;
... to ...
&lt;cut&gt;
             === glibc tests ===

Running elf ...
FAIL: elf/test1

Running string ...
PASS: string/test2
&lt;/cut&gt;.

And output of "make check" from ...
&lt;cut&gt;
FAIL: elf/test1
&lt;/cut&gt;
... to ...
&lt;cut&gt;
FAIL: elf/test1
		=== Summary of results ===
      1 FAIL
      1 PASS
&lt;/cut&gt;.

Signed-off-by: Maxim Kuvyrkov &lt;maxim.kuvyrkov@linaro.org&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>test-container: disable ld.so system cache on DSO detection</title>
<updated>2023-10-23T16:33:29Z</updated>
<author>
<name>Simon Chopin</name>
<email>simon.chopin@canonical.com</email>
</author>
<published>2023-10-05T12:54:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=97290559c3b497fb9012c3f6248cb30afb26da7c'/>
<id>urn:sha1:97290559c3b497fb9012c3f6248cb30afb26da7c</id>
<content type='text'>
When building the testroot, the script runs the newly built ld.so on a
couple of binaries in order to copy over any additional libraries
needed. However, if the dependencies are found in the system cache, it
will be copied over using that path.

This is problematic if the system ld.so and the one built don't have the
exact same search configuration. We encountered this in Ubuntu, where we
build a variant of libc with -fno-omit-frame-pointer for accurate
performance profiling.

This variant is built using a non-standard slibdir to be able to be
co-installed with the default library (e.g. slibdir = /lib/libc6-prof).
Since we have /lib pointing to /usr/lib, any additional dependency
should still be reachable via /usr. However, resolving via the cache
might result in the additional DSOs being copied into $testroot/lib, out
of the search path in the container.

The problem has been triggered by 1d5024f4f052c12e404d42d3b5bfe9c3e9fd27c4
("support: Build with exceptions and asynchronous unwind tables [BZ #30587]")
which introduced a dependency on libgcc_s.so.1 under some circumstances.

Downstream bug: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2031495
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>scripts: Fix fortify checks if compiler does not support _FORTIFY_SOURCE=3</title>
<updated>2023-07-20T20:58:26Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2023-07-20T14:35:54Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=a3090c2c98facbab3d47aa23a94f8d2caeb78d71'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>Switch to UTF-8 for INSTALL</title>
<updated>2023-06-29T18:08:39Z</updated>
<author>
<name>Paul Eggert</name>
<email>eggert@cs.ucla.edu</email>
</author>
<published>2023-06-29T16:20:41Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=84e93afc734a3c30e35ed2d21466a44259ac577e'/>
<id>urn:sha1:84e93afc734a3c30e35ed2d21466a44259ac577e</id>
<content type='text'>
This makes it slightly easier to read, and these days
everybody can read UTF-8.
</content>
</entry>
<entry>
<title>Make sure INSTALL is ASCII plaintext</title>
<updated>2023-06-29T15:07:52Z</updated>
<author>
<name>Siddhesh Poyarekar</name>
<email>siddhesh@sourceware.org</email>
</author>
<published>2023-06-29T15:07:52Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=c14f2e4aaa0f43e2ccb4e77deaa5101dd5af384a'/>
<id>urn:sha1:c14f2e4aaa0f43e2ccb4e77deaa5101dd5af384a</id>
<content type='text'>
Add --disable-encoding to makeinfo flags so that it does not generate
unicode quote glyphs.

Signed-off-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
</content>
</entry>
<entry>
<title>Fix tests-clean Makefile target (bug 30545)</title>
<updated>2023-06-26T13:37:25Z</updated>
<author>
<name>Maxim Kuvyrkov</name>
<email>maxim.kuvyrkov@linaro.org</email>
</author>
<published>2023-06-15T15:25:47Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=7c507f4473911a13273ac535b02fd55edc8e19f9'/>
<id>urn:sha1:7c507f4473911a13273ac535b02fd55edc8e19f9</id>
<content type='text'>
This patch improves tests-clean Makefile target to reliably clean
test artifacts from a build directory.  Before this patch tests-clean
missed around 3k (out of total 9k) .out and .test-result files.

Signed-off-by: Maxim Kuvyrkov &lt;maxim.kuvyrkov@linaro.org&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
</feed>
