Glibc-2.3.3 tarball

Thomas Pegg thomasp at
Tue Jan 13 19:27:59 PST 2004

On Tue, 2004-01-13 at 21:59, Kevin P. Fleming wrote:
> Greg Schafer wrote:
> > The main problem with this approach of automated fixage is that you're not
> > fixing the problems at the core. i.e. the upstream packages need to be fixed
> > eventually so someone needs to be sending patches upstream.
> > 
> Thomas and Jamie, if you haven't been following this discussion on 
> lfs-dev, it relates to the pending upgrade of the LFS book to glibc 
> 2.3.3 (or higher), and the effects that has on coreutils-5.0 
> (specifically, it causes the head/tail utitilies to complain about 
> non-POSIX-200? compliant usage).
> I think when this change goes into LFS, we should make the applying of 
> the coreutils-5.0 patch optional (but included by default). In addition, 
> we can wrap the <make> commands for packages with scripts known to 
> generate the POSIX compliance errors with a <stage> setting 
> _POSIX2_VERSION to the correct value so that head/tail don't complain. 
> This way, the profile is buildable whether you apply the coreutils patch 
> or not, and when each offending package gets "fixed", the explicit 
> setting of _POSIX2_VERSION in that package's profile can be removed.
> Thoughts? Opinions? Is this too radical a departure from the book?
I'll admit that I don't fully understand all this POSIX compliance
stuff, but what you suggest sounds good to me.
LFS User : 4729
Linux User : 298329

More information about the alfs-discuss mailing list