Need help getting latest Perl to compile

[khwilliamson]

We're about to release the latest stable version of Perl, and I want to make sure beforehand that it is working in zopen. (Our EBCDIC version is doing ok.) I last did this a year ago, and did not keep good notes on how to do it, and I'm afraid I'm running into problems following your documentation. I already have the directory structure set up, and have done chtag -R -h -t -cISO8859-1 . on it. But 'zopen build'' insists on doing a git clone. I'm pretty sure that wasn't the case last year. Is there any way to skip that?

I can work around this issue by mv'ing the .git directory from the clone it creates to the one I set up. And, I could convert to set the source url to a fork I create of the patched perl I want to use, but it would be easier if it just could skip that part.

And then it runs Configure, and goes off the rails right away, missing that clang is the compiler to use. It somehow chooses 'c99' which doesn't exist on this system.

Any help is appreciated

[IgorTodorovskiIBM]

At the moment there is no way to skip it.
The git clone is usually done for initial builds and then the zopen community patches are applied on top. Your workaround sounds reasonable for the time being.
We now build with CC=clang and these Configure options: https://github.com/zopencommunity/perlport/blob/main/buildenv#L13-L15
clang is recommended as it is actively being maintained by IBM

[khwilliamson]

Looking through the zopen build documentation, it says I can set the ZOPEN_DEV_TYPE to TARBALL. (or STABLE type). I would think that would do what I wanted, or does it not work?

[IgorTodorovskiIBM]

bashport's buildenv is probably a better example: https://github.com/zopencommunity/bashport/blob/main/buildenv

zopen-build now auto-detects the ZOPEN_DEV_TYPE type based on the extension so you dont have to specify it

[khwilliamson]

I've set it up now a repository for it to clone from, and now it is finishing Configure.

One of the changes I made was to remove a longstanding stray apostrophe that caused a shell script to terminate early. That means that code that hadn't been executed suddenly is. But it fails with

usr/include/features.h:1069:17: error: _POSIX_C_SOURCE 200809L is not supported before z/OS V2R5
#error _POSIX_C_SOURCE 200809L is not supported before z/OS V2R5

But this is V3 I thought. I see this in the command line -mzos-target=zosv2r4 which zopen build adds.

What to do?

[IgorTodorovskiIBM]

-mzos-target=zosv2r4 specifies the min supported OS. If you run with zopen build -u -vv it should update it to zosv2r5. If not, then we should probably investigate :)

[khwilliamson]

The -u worked. Things got a lot further along, but then it fails with

IEW2456E 9207 SYMBOL __strerror_ascii UNRESOLVED. MEMBER COULD NOT BE INCLUDED
FROM THE DESIGNATED CALL LIBRARY.

[khwilliamson]

The -u worked. Things got a lot further along, but then it fails with

IEW2456E 9207 SYMBOL __strerror_ascii UNRESOLVED. MEMBER COULD NOT BE INCLUDED
FROM THE DESIGNATED CALL LIBRARY.

[IgorTodorovskiIBM]

That should be defined in zoslib: https://github.com/zopencommunity/zoslib/blob/zopen2/src/zos-string.c#L213

If you run zopen install zoslib does it say that you're on the latest version?

Can you check the symbols in libzoslib.a with nm to see if it's defined in your copy?

[khwilliamson]

> zopen install zoslib
Processing package: zoslib
Package zoslib is already installed at the requested version: v4.0.3.20260526_072714 and due to the absence of the 'reinstall' flag, will not be reinstalled.

> nm /data/zopen/usr/local/zopen/zoslib/zoslib-v4.0.3.20260526_072714.zos/lib/libzoslib.a | grep strerror_ascii
0 T __strerror_ascii

So the symbol exists. It used to be on Unix that this situation could be caused by the library being placed in the command line too early before another library or object called for that symbol, and we would have to adjust things, perhaps listing the library multiple times. But I don't know how things work in this regard nowadays and on z/OS.

For reference, the entire build log is at /data/karl/perl/ascii/perlport/log.DEV/20260526_134245_build.log and just the failing command

rm -f ../../lib/auto/Compress/Raw/Zlib/Zlib.so
clang -o ../../lib/auto/Compress/Raw/Zlib/Zlib.so -std=c99 -D_EXT -fvisibility=default -D_POSIX_C_SOURCE=200809L -D_XPLATFORM_SOURCE=1 -m64 -std=c99 -D_EXT -fvisibility=default -D_POSIX_C_SOURCE=200809L -D_XPLATFORM_SOURCE=1 -m64 -L/data/zopen/usr/local/zopen/curl/curl-8.13.0.20250516_092121.zos/lib -L/data/zopen/usr/local/zopen/ncurses/ncurses-6.5.20241029_033102.zos/lib -L/data/zopen/usr/local/zopen/zoslib/zoslib-zopen2.20250515_210258.zos/lib -fstack-protector-strong /data/karl/perl/ascii/perlport/perl5/libperl.x -L/data/zopen/usr/local/zopen/curl/curl-8.20.0.20260505_144335.zos/lib -L/data/zopen/usr/local/zopen/libpsl/libpsl-0.21.5.20260310_092221.zos/lib -L/data/zopen/usr/local/zopen/libssh2/libssh2-1.11.1.20260102_060940.zos/lib -L/data/zopen/usr/local/zopen/openssl/openssl-3.3.2.20241101_004716.zos/lib -L/data/zopen/usr/local/zopen/gettext/gettext-1.0.20260430_082423.zos/lib -L/data/zopen/usr/local/zopen/zoslib/zoslib-v4.0.3.20260526_072714.zos/lib   Zlib.o adler32.o compress.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o   \
      \   
  
 IEW2456E 9207 SYMBOL __strerror_ascii UNRESOLVED.  MEMBER COULD NOT BE INCLUDED
          FROM THE DESIGNATED CALL LIBRARY.                                         
 IEW2665S 40FF MODULE *NULL*  IS NON-EXECUTABLE AND WAS NOT SAVED BECAUSE           
          STORENX=NEVER.                                                            
IEW5033 The binder ended with return code 12. 
clang-14: error: linker command failed with exit code 12 (use -v to see invocation)
make[1]: *** [Makefile:515: ../../lib/auto/Compress/Raw/Zlib/Zlib.so] Error 12
make[1]: Leaving directory '/data/karl/perl/ascii/perlport/perl5/cpan/Compress-Raw-Zlib'

[khwilliamson]

I got past this. I think I needed to clean out everything after adding the -u to zopen build

[IgorTodorovskiIBM]

Great! Do you have a working build now?

[khwilliamson]

Perl 5.43.11:

Failed 9 tests out of 2659, 99.66% okay.
../cpan/ExtUtils-MakeMaker/t/02-xsdynamic.t
../cpan/IPC-Cmd/t/01_IPC-Cmd.t
../cpan/IPC-Cmd/t/03_run-forked.t
../cpan/version/t/07locale.t
io/socket.t
porting/authors.t
porting/cmp_version.t
porting/regen.t
run/locale.t

The porting tests don't matter. The socket.t is because z/OS has stricter requirements that POSIX doesn't require. I'm working on a workaround for it. I believe I know hot to get the IPC to work;. I have to investigate the locale ones, which leaves only the MakeMaker one, which also fails the EBCDIC version, so it is a z/OS generic problem. I think I'd like help with this one. One of the zopen patches is to the failing file

But basically we're in good shape. 5.43.11 has changes that remove the need for a couple of your patches. I'll submit a pull request for those.

And I have questions/comments on some of the other zopen patches. I'm unsure of the best way to deal with those. Suggestions welcome. I could submit them as a pull request to Perl's repository and then do a review. That's my best guess now.

[IgorTodorovskiIBM]

Yes, if you want to go ahead and submit PRs that would be best. We have automation to trigger builds when a PR is created. FYI @HarithaIBM