> ... the IBM Open XL C/C++ compiler is not compatible with XL C/C++
> or xlclang compilers. This incompatibility may pose challenges.
> Python 3.11 is developed using IBM Open XL C/C++, while Python
> 3.10 uses xlclang. As a result, binary packages created for
> Python 3.10 won't work with the IBM Open XL C/C++ compiler.
Come again?
Are you saying that object code for this platform produced by one compiler
is incompatible with object code for this platform produced by the other
compiler?
The broken compiler "can only be used for open source", but open source
aficionados would surely use the alternative when compiling their wares.
Free as in speech, not just free as in beer.
Perhaps the broken compiler should come with a surgeon general's warning.
(A meaningful reference in the US where cigarette packaging has, now for
decades, been required to state "this product is bad for you".)
We continue further down the rabbit hole of software being used for
controlling people rather than software being used for controlling
machines.
-- R; <><
On 8/9/23 02:58, David Crayford wrote:
As if we didn’t already have enough z/OS C/C++ compilers :)
I've recently been working on Python bindings for z/OS products and wanted to
share some useful notes. IBM recently released the IBM C/C++ for Open
Enterprise Languages on z/OS compiler [1], a free version of IBM Open XL C/C++,
which is a port of LLVM/clang. This compiler can only be used for open source.
For example, to build Python, Node, go packages that require a build phase when
installed or contributing to z/OS open source projects. It's important to note
that the IBM Open XL C/C++ compiler is not compatible with XL C/C++ or xlclang
compilers. This incompatibility may pose challenges. Python 3.11 is developed
using IBM Open XL C/C++, while Python 3.10 uses xlclang. As a result, binary
packages created for Python 3.10 won't work with the IBM Open XL C/C++ compiler.
To overcome this issue, the recommended solution is to build Python distributions that include
the source C/C++ code. During the installation process using pip, this code can be built. There
are a few issues with the new compiler. Firstly, there is no support for "OS"
linkage, meaning no #pragma linkage(module,OS) or extern 'OS' {}. Custom thunk routines need to
be written to address this. Additionally, the compiler supports inline assembly, but the
-qasmlib=<macro-library> option is not available, making macros unusable. A workaround I
found is to assemble some HLASM code and copy-paste from the listing.
Moreover, the runtime library is not entirely compatible with XL C/C++. I
discovered that the __amrc structure is missing, which breaks my pzfile package
and makes accessing VSAM files nearly impossible. I plan to open a case with
IBM to address this issue.
Another limitation is that the compiler does not produce source/assembly
listings. Furthermore, thread level storage is not supported, which complicates
the process of porting certain libraries.
On a positive note, IBM has open-sourced their zoslib library [2], which
assists in porting applications to z/OS. There is a lot of useful function in
this library. It supports dynamically loading and calling modules using thunk
routines. Unfortunately, there is a comment in the code which states it only
works with xlclang. The library is Apache 2.0 licensed but it has IBM
copyright. I'm not a lawyer so I'm unsure of the legalities of using this
library for product code.
[1]
https://www.ibm.com/docs/en/cloud-paks/z-modernization-stack/2023.2?topic=languages-cc-open-enterprise-zos
[2] https://github.com/ibmruntimes/zoslib
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
