Front page | perl.perl5.porters |
Postings from February 2013
Re: New EBCDIC branch available
From:
Karl Williamson
Date:
February 27, 2013 05:21
Subject:
Re: New EBCDIC branch available
Message ID:
512D97D6.5000809@khwilliamson.com
On 02/26/2013 08:41 PM, John Goodyear wrote:
> Karl,
> I pulled down a snapshot from the link you provided.
>
> Here is the configure output: of
>
> sh ./Configure -Dprefix=/u/jgood/local -Dusedl -Dusedevel -de >
> configure.out 2>&1&
>
>
> /(See attached file: configure.out)/
>
>
> WRT to the errors previously seen during the makedepend step, besides
> the errors about missing headers which don't yet exist in the makedepend
> phase, the only remain error is:
>
> 2002 Finding dependencies for pp_sys.o.
> 2003 ERROR CCN3010 ./time64.c:478 Macro PeRl_CaTiFy invoked with a
> null argument for parameter a.
> 2004 ERROR CCN3010 ./time64.c:478 Macro PeRl_CaTiFy invoked with a
> null argument for parameter a.
>
> However,there is a new wrinkle. the grep issued from cppstdin causes
> this notification for each source file:
>
> grep: FSUM9950 input lines truncated - result questionable
>
> Apparently grep is limited to 2048 bytes. The workaround is to use
> fgrep instead. I did the replacement of grep for fgrep in cppstdin,
> and the error went away. I see Configure is conditionalized for AIX,
> so perhaps adding another condition for z/OS. However the questions are
>
> 1) is is what changed to cause this to suddenly appear?
> 2) do you have line limit issues on any other platforms? (another
> one discussed further below for inline.h
It's possible that joining continued lines together caused lines to
exceed you 2048 limit. There are limits on other platforms. I remember
demerphq changing a macro generator to avoid exceeding a certain size,
but I don't remember what that number is. The line joining could be
changed to remove trailing/leading blanks when doing the join. That
would cut the frequency of the errors
>
>
> Getting to the compile, I get roughly 1500 of these CCN4108
> informationals for every time __attribute__ is seen when compiling a file:
>
> INFORMATIONAL CCN4108 ./proto.h:4534 The use of keyword
> '__attribute__' is non-portable.
>
>
> If we are comfortable with this issue, then adding ,SUPPRESS(CCN4108)
> will quite the compiler down. Of course the parens have to be inside
> double quotes to keep the shell happy, so ccflags in hints/os390.sh
> would become:
>
> ccflags="$ccflags -W 0,float(ieee),SUPPRESS(CCN4108)"
I wonder if your compiler understands __attribute__. I think it must,
but someone who knows Configuration should comment on this and using fgrep.
>
>
>
> *A new error:*
>
> There is a new error that shows up on the first source file
> (perlmini.c), which is in inline.h
>
> 163 return isIDFIRST_lazy_if(p,1);
>
> ERROR CCN3277 ./inline.h:163 Syntax error: possible missing ')' or
> ','?
> 6 ERROR CCN3023 ./inline.h:163 Expecting function or
> pointer to function.
> 7 ERROR CCN3275 ./inline.h:163 Unexpected text ']' encountered.
> 8 ERROR CCN3277 ./inline.h:163 Syntax error: possible
> missing ')' or ','?
> 9 ERROR CCN3023 ./inline.h:163 Expecting function or
> pointer to function.
> 10 ERROR CCN3277 ./inline.h:163 Syntax error: possible
> missing ')' or ','?
>
> The same general pattern of errors occurs at lines 171, and 185/186
> of the file. I compille perlmini.c with the -E flag to generated
> the proprocessor output. The attached file perlmini.out has result
> of how line 163 was expanded.
> /(See attached file: perlmini.out)/
>
> It looks like the macro expasion split the array pPL_e2utf across 2
> lines, and also inserted a couple of parenthesis. It happened right
> at offset 2048, so it seems we're hitting another 2K limit, however
> I'm doing some research to verify this.
>
> Has this been experienced on any other platforms?
I don't see what that array is included so many times, and will have to
look at it tomorrow. That array is not used on other platforms.
>
>
> John Goodyear
>
>
>
> Karl Williamson wrote on 02/26/2013 04:28:01 PM:
>
>
> > Subject: New EBCDIC branch available
> >
> > I have created a topic branch for work on EBCDIC at
> > http://perl5.git.perl.org/perl.git/khw/ebcdic
> >
> > It is my expectation that this will serve as the on-going repository for
> > work on this.
> >
> > John should build off this. I believe it fixes a number of problems in
> > the existing code, and isolates the need for EBCDIC awareness to just a
> > few code areas.
> >
> > I'm pretty sure that the utilities like h2xs would not compile prior to
> > these patches.
> >
> > The next step is to get a successful build of miniperl. This actually
> > is fairly early in the build of perl.
> >
> > Once that is done, a bunch of things need to be regen'd to know about
> > the EBCDIC character set, before the make can successfully continue.
> >
> > Having an older running perl would help in this process, but I'd like to
> > figure out and prove-in, and document the steps needed to boot-strap
> > perl onto a computer without using older infrastructure.
> >