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.
>
