Skip Menu |
Report information
Id: 2087
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: pvhp [at] forte.com
Cc:
AdminCc:

Operating System: os390
PatchStatus: (no value)
Severity: medium
Type: (no value)
Perl Version: (no value)
Fixed In: (no value)



Date: Thu, 3 Feb 2000 12:28:49 -0800 (PST)
From: Peter Prymmer <pvhp [...] forte.com>
To: perlbug [...] perl.org
Subject: Not OK: perl 5.00564 on os390
Download (untitled) / with headers
text/plain 4.4k
5.5.640 cannot be built on OS/390 R2.5. FWIW we see a couple of new blemishes during a run of `sh Configure -des`, such as: #### Figuring out host name... Your host name appears to be "LPAR23". Right? [y] /bin/awk: FSUM6003 input file "hosts": EDC5000I No error occurred. /bin/awk: FSUM6003 input file "hosts": EDC5000I No error occurred. What is your domain name? [.uucp] What is your e-mail address? [PVHP@lpar23.uucp] Perl administrator e-mail address [PVHP@lpar23.uucp] #### Then a bit later on a test compile appears a bit disconcerting to this compiler: #### <poll.h> found. Guessing which symbols your C compiler and preprocessor define... ERROR CBC3199 ./.1090519113.c:2 #ifdef directive requires a macro name. ERROR CBC3199 ./.1090519113.c:7 #ifdef directive requires a macro name. FSUM3065 The COMPILE step ended with return code 12. FSUM3017 Could not compile .1090519113.c. Correct the errors and try again. tcsetattr() found. #### The following warning was seen during the subsequent build (long lines truncated): #### `sh cflags libperl.a util.o` util.c CCCMD = c89 -DPERL_CORE -c -DMAXSIG=38 -DOEMVS -D_OE_SOCKETS -D_XOPE WARNING CBC3193 ./util.c:3600 The size of this type is zero. FSUM3065 The COMPILE step ended with return code 4. `sh cflags libperl.a mg.o` mg.c #### Finally the build fails with utf8::SWASHNEW problems (long line wrapped & munged): #### You may see some irrelevant test failures if you have been unable to build lib/Config.pm. cd t && (rm -f perl; /bin/ln -s ../miniperl perl) \ && ./perl TEST base/*.t comp/*.t cmd/*.t io/*.t op/*.t pragma/*.t </dey Can't locate object method "SWASHNEW" via package "utf8". make[1]: [minitest] Error 255 (ignored) make[1]: Leaving directory `/bld6/pvhp/perl/perl5.5.640' make: [extra.pods] Error 1 (ignored) ./miniperl configpm configpm.tmp Can't locate object method "SWASHNEW" via package "utf8". make: *** [lib/Config.pm] Error 255 #### Hmm... Is there a way around making the call to SWASHNEW? I tried this desperate little subterfuge: $ diff -u utf8.c.orig utf8.c --- utf8.c.orig Thu Feb 3 12:07:15 2000 +++ utf8.c Thu Feb 3 12:08:31 2000 @@ -680,10 +680,14 @@ save_re_context(); if (PL_curcop == &PL_compiling) /* XXX ought to be handled by lex_start/ strncpy(tmpbuf, PL_tokenbuf, sizeof tmpbuf); +#ifdef __MVS__ + retval = &PL_sv_undef; +#else if (call_method("SWASHNEW", G_SCALAR)) retval = newSVsv(*PL_stack_sp--); else retval = &PL_sv_undef; +#endif LEAVE; POPSTACK; if (PL_curcop == &PL_compiling) { End of Diff. But then during the subseqent rebuild attempt I see: #### ./miniperl -w -Ilib -MExporter -e '<?>' || make minitest SWASHNEW didn't return an HV ref. make[1]: Entering directory `/bld6/pvhp/perl/perl5.5.640' You may see some irrelevant test failures if you have been unable to build lib/Config.pm. cd t && (rm -f perl; /bin/ln -s ../miniperl perl) \ && ./perl TEST base/*.t comp/*.t cmd/*.t io/*.t op/*.t pragma/*.t </dey SWASHNEW didn't return an HV ref. make[1]: [minitest] Error 255 (ignored) make[1]: Leaving directory `/bld6/pvhp/perl/perl5.5.640' ./miniperl configpm configpm.tmp SWASHNEW didn't return an HV ref. make: *** [lib/Config.pm] Error 255 #### Suggestions on how to go about compiling the utf8 stuff on a statically linked platform would be appreciated. Thanks. Peter Prymmer Summary of my perl5 (revision 5.0 version 5 subversion 640) configuration: Platform: osname=os390, osvers=05.00, archname=os390 uname='os390 lpar23 05.00 02 9672 ' config_args='-des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usesocks=undef useperlio=undef d_sfio=undef use64bits=undef uselargefiles=define usemultiplicity=undef Compiler: cc='c89', optimize=' ', gccversion= cppflags='' ccflags ='-DMAXSIG=38 -DOEMVS -D_OE_SOCKETS -D_XOPEN_SOURCE_EXTENDED -D_ALL_SOURCE -DYYDYNAMIC -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=undef, longlongsize=, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lm -lc libc=, so=a, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_none.xs, dlext=none, d_dlsymun=undef, ccdlflags='' cccdlflags='-W 0,dll,"langlvl(extended)"', lddlflags=''
From: sthoenna [...] efn.org (Yitzchak Scott-Thoennes)
To: perl5-porters [...] perl.org
Subject: Re: [ID 20000203.006] Not OK: perl 5.00564 on os390
Date: Thu, 03 Feb 2000 14:51:22 -0800
Download (untitled) / with headers
text/plain 2.3k
In article <200002032028.MAA08336@brio.forte.com>, Peter Prymmer <pvhp@forte.com> wrote: Show quoted text
>Then a bit later on a test compile appears a bit disconcerting to this >compiler: > >#### ><poll.h> found. >Guessing which symbols your C compiler and preprocessor define... >ERROR CBC3199 ./.1090519113.c:2 #ifdef directive requires a macro name. >ERROR CBC3199 ./.1090519113.c:7 #ifdef directive requires a macro name. >FSUM3065 The COMPILE step ended with return code 12. >FSUM3017 Could not compile .1090519113.c. Correct the errors and try again. >tcsetattr() found. >####
FWIW, I got: Guessing which symbols your C compiler and preprocessor define... :2: warning: `#ifdef' argument starts with a digit :7: warning: `#ifdef' argument starts with a digit perl -V: Summary of my perl5 (revision 5.0 version 5 subversion 640) configuration: Platform: osname=os2, osvers=2.30, archname=os2 uname='os2 localhost 2 2.30 i386 ' config_args='-des -D prefix=d:/perl' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usesocks=undef useperlio=undef d_sfio=undef use64bits=undef uselargefiles=define usemultiplicity=undef Compiler: cc='gcc', optimize='-O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s', gccversion=2.8.1 cppflags='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -D_EMX_CRT_REV_=62' ccflags ='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -D_EMX_CRT_REV_=62' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc', ldflags ='-Zexe -Zomf -Zmt -Zcrtdll -Zstack 32000' libpth=d:/emx/lib d:/emx/lib/mt libs=-lsocket -lm -lbsd libc=d:/emx/lib/mt/c_import.lib, so=dll, useshrplib=true, libperl=libperl.lib Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-Zdll', lddlflags='-Zdll -Zomf -Zmt -Zcrtdll -s' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under os2 Compiled at Feb 2 2000 12:17:27 %ENV: PERL_SH_DIR="d:\BIN" @INC: d:/perl/lib/5.5.640/os2 d:/perl/lib/5.5.640 d:/perl/lib/site_perl/5.5.640/os2 d:/perl/lib/site_perl/5.5.640 .
To: Peter Prymmer <pvhp [...] forte.com>
Cc: perl5-porters [...] perl.org
Subject: Re: [ID 20000203.006] Not OK: perl 5.00564 on os390
Date: Thu, 03 Feb 2000 22:26:24 -0800
From: Gurusamy Sarathy <gsar [...] ActiveState.com>
Download (untitled) / with headers
text/plain 1.2k
On Thu, 03 Feb 2000 12:28:49 PST, Peter Prymmer wrote: Show quoted text
>5.5.640 cannot be built on OS/390 R2.5.
[...] Show quoted text
>cd t && (rm -f perl; /bin/ln -s ../miniperl perl) \ > && ./perl TEST base/*.t comp/*.t cmd/*.t io/*.t op/*.t pragma/*.t ></dey >Can't locate object method "SWASHNEW" via package "utf8".
Hmm. I think EBCDIC in general is in big trouble now that we're switching to UTF-8 as the internal representation for text. (We basically assume that any byte over 127 is fair game for being treated as a character, which obviously won't work on EBCDIC.) The EBCDIC folks might want to bite-the-bullet and re-architect their port. What needs to happen is that all the character data coming into Perl needs to be canonicalized to Unicode, and character data going out needs to be turned back into EBCDIC. That includes the script itself. Once we have I/O disciplines working properly it should be a simple matter of setting up the appropriate default disciplines for I/O. That covers I/O, but the harder part is going to be system calls. You'll need to create a set of wrappers along the lines of the interface defined in iperlsys.h and use that instead of the straight calls into the CRT/system. Sarathy gsar@ActiveState.com
Date: Fri, 4 Feb 2000 16:22:17 -0800 (PST)
From: Peter Prymmer <pvhp [...] forte.com>
To: gsar [...] ActiveState.com, perl5-porters [...] perl.org
Subject: Re: [ID 20000203.006] Not OK: perl 5.00564 on os390
Download (untitled) / with headers
text/plain 1.4k
Gurusamy Sarathy wrote in response to me: Show quoted text
> On Thu, 03 Feb 2000 12:28:49 PST, Peter Prymmer wrote:
> >5.5.640 cannot be built on OS/390 R2.5.
> [...]
> >cd t && (rm -f perl; /bin/ln -s ../miniperl perl) \ > > && ./perl TEST base/*.t comp/*.t cmd/*.t io/*.t op/*.t pragma/*.t > ></dey > >Can't locate object method "SWASHNEW" via package "utf8".
> > Hmm. I think EBCDIC in general is in big trouble now that we're > switching to UTF-8 as the internal representation for text. (We > basically assume that any byte over 127 is fair game for being > treated as a character, which obviously won't work on EBCDIC.)
Ouch. Show quoted text
> The EBCDIC folks might want to bite-the-bullet and re-architect their > port. What needs to happen is that all the character data coming > into Perl needs to be canonicalized to Unicode, and character data > going out needs to be turned back into EBCDIC. That includes the > script itself. Once we have I/O disciplines working properly > it should be a simple matter of setting up the appropriate default > disciplines for I/O. That covers I/O, but the harder part is going > to be system calls. You'll need to create a set of wrappers > along the lines of the interface defined in iperlsys.h and use that > instead of the straight calls into the CRT/system.
"Eat lead EBCDIC!", this is going to hurt. Well thanks for the culinary tip. I suspected we were living on borrowed time :-) Peter Prymmer


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org