Re: 4.3-030 - fails to build on older HP-UX

[H.Merijn Brand]

On Mon, 27 Oct 2014 07:42:39 -0700, Linda Walsh <bash@tlinx.org> wrote:

> H.Merijn Brand wrote:
> > 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some
> > very small edits) but fails HP-UX 11.11, 11.00 and 10.20
> > 
> > The first reason is the use of C++ style comments in the source.
> > The fix is easy. Just use plain ANSI comments. Old(er) ANSI C-compilers
> > do NOT recognize // as command (an IMHO they should not)
> ----
> The POSIX standard after 2002 is no longer guaranteed to be compatible
> with the original POSIX standard.  POSIX went from descriptive to prescriptive
> after 2002 and no longer limits itself to what was out there and compatible
> with the original POSIX specification, but has gone into incompatible
> specifications for 2007, 2010 et al.  I.e. the new POSIX doesn't adhere
> to the original POSIX mission statement and is arguably not POSIX, but the
> new group bought the name and has no responsibility to compatibility
> with the original group's mission statement or specification.

Yeah, standards++

> Sorta like "AT&T" being bought by PacBell (SBC at the time).
> They are different companies with completely different quality
> metrics and mission statements.  However, many or most
> GNU based projects, wanting industry validation, have used
> compliance with the new POSIX[sic] spec as a "promotion point".
> 
> Thus, for example, since strtoll was added for ISO C 2001 compatibility,
> any SW that isn't up to the level of 2001 standards (like
> ANSI C98 and prior) isn't compatible to the latest rev of
> the POSIX standard.  The fact that post 2002 versions of POSIX
> aren't compatible with the original mission statement of the original
> standard is not relevant.
> 
> > The three files that ought to be fixed are
> > 
> >  lib/readline/colors.h
> >  lib/readline/colors.h
> >  lib/readline/parse-colors.c
> ---
> Maybe a sed script could filter these?  Either that or if you want to
> use the latest software (bash 4.3) on these system, then they need
> to have the latest tool chains?

OTOH How difficult is it to stick to consistent use of /* ... */ ?
hand edited those three and that "resolves" the issue, but the issue is
so unnecessary

> > The next issue is harder to fix. These three OS's do not seem to have
> > easy detectable wide-char support.
> ===
> Not sure how easy this would be to hack, but the last issue is fairly
> trivial.
> 
> > The last issue is building 64bit version on 11.11:
> > 
> > ld: Unsatisfied symbol "__strtoull" in file 
> > ./builtins/libbuiltins.a[printf.o]
> > ld: Unsatisfied symbol "__strtoll" in file general.o
> > 
> > as on 64bit build strtoull does not exist, as strtoul already *is*
> > strtoull (likewise for strtoll vs strtol)
> ---
>       Right, so, adding a local lib that has an strtoull call
> that simply calls the local strtoul call would seem to be a lowest
> touch solution.
>       
>       However, the question remains, why would you want or require
> a newest-tool-version like bash 4.3 on an old system that doesn't support
> the newest-tool-version "tool chain"?

Yes, I do

There are several reasons
• I have these systems open for OpenSource developers and putting them
  in a 1972 version of the Bourne shell will make them scream. Besides
  the fact that the old bourne- or posix-shells miss a lot of features
  that modern developers love to see, putting them in something better
  that I already have ported (like tcsh) is probably not making their
  lives any better
• Security issues. I had an old version (ranging from 3.0 to 3.2.48)
  version of bash already installed. Those are outdated and many fixes
  have been made since both security-wise and feature-wise. I find it
  my task to have something reasonable recent available
• Some tools require bash (for testing), like git. You won't be able
  to pass the git test suite without bash. Let's not make their lives
  harder by not having it around. (You don't want to port GNU projects
  using HP's make either!)

>       Systems of 15-20 years ago that want to build current
> tools need to be willing to update their build-chain tools to the
> level required by 'current tools' -- or go suffer an increasing work
> load of backporting current tools (often at the expense of new
> development).

Agree, but why make it harder from both sides?

> Cheers!
> -L

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

pgp0UGWyYyriB.pgp
Description: OpenPGP digital signature