Posix Compliance [Was Re: Glibc-2.3.3 tarball]
Ryan.Oliver at pha.com.au
Ryan.Oliver at pha.com.au
Wed Jan 14 23:54:26 PST 2004
Steve Martin wrote:
> Nor shall I be including it in mine, the attached script
> takes the pain out of the LFS build when you don't use the
> patch; I have this included as two functions in my main
> build scripts which get called after each package is unpacked
> and before applying any patches. So far so good.
You may want to check out
or build-init.2.3.x.sh from the old plfs scripts...
( http://www.linuxfromscratch.org/~ryan )
Theres more to it than just head and tail...
I believe Zack Winkles also extended the old sed script (Zack?) and
it can also be found under his home directory
( http://www.linuxfromscratch.org/~winkie )
Even these don't catch everything ( one notable one is in glibc,
Teemu should have the patch )
Eventually I'll write a perl script to properly parse through and
fix all core/diffutils posix2 breakages...
Ideally however we'd just hack core/diffutils to honor the POSIXLY_CORRECT
environment variable (as it fscking well should, this
should be the trigger, if you want strict conformance, set the env var).
Just because the a system identifies that it supports posix 200112L
doesn't mean that the behaviour of everything should change with it.
Good luck convincing Jim Meyering of this, we'll have to do it
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.
You don't get too far with that
(I got a nice short response from Zack Weinberg on the gcc list when
this first popped up may last year,
"30 years of shell scripts rely on the old syntax,
put the old behaviour back". :-) ).
A simple addition to the autotools to check for it would be handy,
but you'll be spending a hell of a long time hacking around in
the packages m4/ directories updating them...
In an ideal world
a) 200112L compliant systems should have the ability to use the
new syntax, but it shouldn't be compulsory.
b) POSIXLY_CORRECT should trigger tools to conform to the
appropriate posix level defined for the system and the
c) Autotools would understand to use the new syntax if a test
confirms 200112L AND POSIXLY_CORRECT (simple test).
But I guess this must just make too much sense to Jim and team...
Ahhh well... what can you do...
Personally I like this little snippet here
"Many of the GNU tools comply with POSIX by default, except for where the
author thinks the POSIX standard is wrong or dumb. :) As a result, some
programs also check if a variable named POSIX_ME_HARDER is set as an
acceptable alias for POSIXLY_CORRECT"
'Bout sums it up methinks ;-)
More information about the lfs-dev