This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: linknamespace failures
- From: Chris Metcalf <cmetcalf at ezchip dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 22 Dec 2014 15:58:52 -0500
- Subject: Re: linknamespace failures
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp dot mailfrom=cmetcalf at ezchip dot com;
- References: <5494F35F dot 2000107 at ezchip dot com> <alpine dot DEB dot 2 dot 10 dot 1412201107240 dot 20593 at digraph dot polyomino dot org dot uk> <54973679 dot 2020901 at ezchip dot com> <alpine dot DEB dot 2 dot 10 dot 1412221252300 dot 11756 at digraph dot polyomino dot org dot uk>
On 12/22/2014 8:06 AM, Joseph Myers wrote:
On Sun, 21 Dec 2014, Chris Metcalf wrote:
Yes, I think the strstr -> strnlen bug that I fixed caused a lot of
tests to fail, and when I investigated the .out files, I saw other things,
Remember filing bugs in Bugzilla when fixing anything that would have been
user-visible in a release. That generally applies to bugs shown up by
linknamespace test failures, unless the bug itself is new since the last
release (not just the tests being new).
I filed bugs for the couple of namespace issues I fixed recently,
and updated NEWS and the ChangeLog with those bug numbers.
On tile we use the no-op version in math/feupdateenv.c, but surely we should
be calling these routines with the __feupdateenv entry point names?
See for example
<https://sourceware.org/ml/libc-alpha/2014-12/msg00749.html>, for which
I'm hoping for a sanity check, addressing such issues for feraiseexcept.
I filed bug 17748 for this issue, but I need to get back to other work for
the time being, so I won't be looking into a real fix in the short term.
I suppose another hack fix would be to just add some empty #defines for
tile to do nothing for the fe* functions that are causing issues here.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com