Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not OK: perl 5.00564 on os390 #1128

Closed
p5pRT opened this issue Feb 3, 2000 · 5 comments
Closed

Not OK: perl 5.00564 on os390 #1128

p5pRT opened this issue Feb 3, 2000 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 3, 2000

Migrated from rt.perl.org#2087 (status was 'resolved')

Searchable as RT2087$

@p5pRT
Copy link
Author

p5pRT commented Feb 3, 2000

From pvhp@forte.com

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

Inline Patch
--- 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=''

@p5pRT
Copy link
Author

p5pRT commented Feb 3, 2000

From @ysth

In article <200002032028.MAA08336@​brio.forte.com>,
Peter Prymmer <pvhp@​forte.com> wrote​:

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
  .

@p5pRT
Copy link
Author

p5pRT commented Feb 3, 2000

From @gsar

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

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

@p5pRT
Copy link
Author

p5pRT commented Feb 4, 2000

From [Unknown Contact. See original ticket]

Gurusamy Sarathy wrote in response to me​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Apr 3, 2010

@chorny - Status changed from 'stalled' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant