[lfs-dev] Upcoming glibc
Douglas R. Reno
renodr2002 at gmail.com
Sun Feb 14 09:52:40 PST 2016
On Sun, Feb 14, 2016 at 11:38 AM, Douglas R. Reno <renodr2002 at gmail.com>
> On Sun, Feb 14, 2016 at 11:33 AM, Bruce Dubbs <bruce.dubbs at gmail.com>
>> I just found out this morning that glibc-2.23 is to be released soon.
>> Looking at https://sourceware.org/glibc/wiki/Release/2.23, it looks like
>> most of their objectives for the release have been made.
>> Right now I'm building a full LFS at -j1 for size and time statistics and
>> have been planning to go through the release process today for 7.9-rc1.
>> The question is whether we should wait for the latest glibc? I'm not
>> 100% comfortable about updating a critical package just before release.
>> Waiting will certainly push back the stable release.
>> There are some security bugs fixed in the latest version:
>> but they look pretty esoteric to me.
>> -- Bruce
> I believe that we should probably release anyway. Although there are some
> security bugs fixed in the latest version, pushing back the release doesn't
> seem right with such a critical package, since it will likely require more
> testing, more suited to a development version.
> Douglas R. Reno
> "The header file regexp.h (not to be confused with regex.h) has been
removed, leaving behind a stub containing only an #error directive. No
packaging changes are required, and binary backward compatibility is
preserved, but any program that uses this header will fail to compile with
This header and the API it defines were formerly part of SUS, but were
deprecated in 1994 and removed from the standard in 2001. Moreover, the
glibc implementation suffered from bugs that had gone unnoticed from 1996
through 2009, including memory leaks which were impractical to fix. See bug
18681 <https://sourceware.org/bugzilla/show_bug.cgi?id=18681> for more
Programs that use this header are expected to be rare. They should be
updated to use regex.h
and the somewhat different API defined there, instead. regcomp
is the replacement for the compile function and its associated macros, and
is the replacement for the step and advance functions and their associated
It is possible that a few programs in BLFS might still use this header
file, possibly a few of the older packages.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lfs-dev