Omr: Problems building on z/OS

[daveyc]

I'm getting the following error building on z/OS. I have set _CC_CCMODE=1

FSUM3010 Specify a file with the correct suffix (.C, .hh, .i, .c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -L..
gmake[2]: *** [../../hookgen] Error 1

[mgaudet]

Can you show more of you configuration output? (_i.e._ what did you pass via configure?)

[daveyc]

I didn't supply any options to configure. If you can give me the heads up what I need for a z/OS build it will be greatly received. I've ran ./configure --help and see lots of options but don't have time right now to work it all out.

[daveyc]

If I can get the build working I will document it in a readme for z/OS build.

[mgaudet]

Did you provide a value for SPEC -- if so, which :) ?

[daveyc]

No I didn't supply a value for SPEC. I was assuming the configure script would be able to deduce it's a z/OS system by running uname and I wouldn't have to specify any arguments or set any environment variables.

[daveyc]

Here's the output from configure. OMR_HOST_OS is correctly set to zos which the makefiles use to control the linker.

AR='ar'
ARFLAGS=''
AS='as'
CC='cc'
CCLINK='$(CC)'
CCLINKEXE='$(CCLINK)'
CCLINKSHARED='$(CCLINK)'
CFLAGS=''
CPP='cc -E'
CPPFLAGS=''
CXX='xlC_x'
CXXFLAGS=''
CXXLINK='$(CXX)'
CXXLINKEXE='$(CXXLINK)'
CXXLINKSHARED='$(CXXLINK)'
DEFS='-DHAVE_CONFIG_H'
ECHO_C='\c'
ECHO_N=''
ECHO_T=''
EGREP='/u/doc/bin/grep -E'
EXEEXT=''
GLOBAL_ARFLAGS=''
GLOBAL_CFLAGS=''
GLOBAL_CPPFLAGS=''
GLOBAL_CXXFLAGS=''
GLOBAL_INCLUDES=''
GLOBAL_LDFLAGS=''
GLOBAL_LIBPATH=''
GLOBAL_SHARED_LIBS=''
GLOBAL_STATIC_LIBS=''
GREP='/u/doc/bin/grep'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
OBJCOPY='objcopy'
OBJEXT='o'
OMRGLUE='./example/glue'
OMRGLUE_CFLAGS=''
OMRGLUE_CPPFLAGS=''
OMRGLUE_CXXFLAGS=''
OMRGLUE_INCLUDES=''
OMRTHREAD_LIB_AIX='0'
OMRTHREAD_LIB_UNIX='0'
OMRTHREAD_LIB_WIN32='0'
OMRTHREAD_LIB_ZOS='1'
OMR_ARCH_ARM='0'
OMR_ARCH_POWER='0'
OMR_ARCH_S390='0'
OMR_ARCH_X86='0'
OMR_COMPANY_COPYRIGHT=''
OMR_COMPANY_NAME=''
OMR_CROSS_COMPILE='0'
OMR_CROSS_CONFIGURE=''
OMR_DEBUG='1'
OMR_ENHANCED_WARNINGS='1'
OMR_ENV_DATA64='0'
OMR_ENV_GCC='0'
OMR_ENV_LITTLE_ENDIAN='0'
OMR_EXAMPLE='0'
OMR_GC='1'
OMR_GC_ALLOCATION_TAX='1'
OMR_GC_ARRAYLETS='1'
OMR_GC_BATCH_CLEAR_TLH='1'
OMR_GC_COMBINATION_SPEC='1'
OMR_GC_COMPRESSED_POINTERS='0'
OMR_GC_CONCURRENT_SCAVENGER='0'
OMR_GC_CONCURRENT_SWEEP='0'
OMR_GC_DEBUG_ASSERTS='1'
OMR_GC_DYNAMIC_CLASS_UNLOADING='0'
OMR_GC_HEAP_CARD_TABLE='1'
OMR_GC_HYBRID_ARRAYLETS='0'
OMR_GC_IDLE_HEAP_MANAGER='0'
OMR_GC_LARGE_OBJECT_AREA='1'
OMR_GC_LEAF_BITS='0'
OMR_GC_MINIMUM_OBJECT_SIZE='1'
OMR_GC_MODRON_COMPACTION='0'
OMR_GC_MODRON_CONCURRENT_MARK='0'
OMR_GC_MODRON_SCAVENGER='0'
OMR_GC_MODRON_STANDARD='1'
OMR_GC_NON_ZERO_TLH='1'
OMR_GC_OBJECT_ALLOCATION_NOTIFY='0'
OMR_GC_OBJECT_MAP='0'
OMR_GC_REALTIME='0'
OMR_GC_SEGREGATED_HEAP='0'
OMR_GC_STACCATO='0'
OMR_GC_THREAD_LOCAL_HEAP='1'
OMR_GC_TLH_PREFETCH_FTA='0'
OMR_GC_VLHGC='0'
OMR_HOST_ARCH='s390'
OMR_HOST_OS='zos'
OMR_INTERP_COMPRESSED_OBJECT_HEADER='0'
OMR_INTERP_HAS_SEMAPHORES='1'
OMR_INTERP_SMALL_MONITOR_SLOT='0'
OMR_JIT='0'
OMR_JITBUILDER='0'
OMR_NOTIFY_POLICY_CONTROL='0'
OMR_OMRSIG='1'
OMR_OPTIMIZE='1'
OMR_OPT_CUDA='0'
OMR_PORT='1'
OMR_PORT_ALLOCATE_TOP_DOWN='0'
OMR_PORT_ASYNC_HANDLER='0'
OMR_PORT_CAN_RESERVE_SPECIFIC_ADDRESS='0'
OMR_PORT_NUMA_SUPPORT=''
OMR_PORT_ZOS_CEEHDLRSUPPORT='0'
OMR_PRODUCT_DESCRIPTION='OMR 0.1 '
OMR_PRODUCT_VERSION='0.1'
OMR_RAS_TDF_TRACE='1'
OMR_RTTI='0'
OMR_TARGET_DATASIZE='32'
OMR_TEST_COMPILER='0'
OMR_THREAD='1'
OMR_THR_ADAPTIVE_SPIN='1'
OMR_THR_CUSTOM_SPIN_OPTIONS='0'
OMR_THR_FORK_SUPPORT='0'
OMR_THR_JLM='1'
OMR_THR_JLM_HOLD_TIMES='1'
OMR_THR_LOCK_NURSERY='1'
OMR_THR_SPIN_WAKE_CONTROL='0'
OMR_THR_THREE_TIER_LOCKING='0'
OMR_THR_TRACING='0'
OMR_THR_YIELD_ALG='0'
OMR_TOOLCHAIN='xlc'
OMR_UNDEFINED_JIT_VERSION_STRING='#define OMR_JIT_VERSION_STRING "<Unknown>"'
OMR_UNDEFINED_VERSION_STRING='#define OMR_VERSION_STRING "<Unknown>"'
OMR_VALGRIND_MEMCHECK='0'
OMR_WARNINGS_AS_ERRORS='1'
PACKAGE_BUGREPORT=''
PACKAGE_NAME='OMR'
PACKAGE_STRING='OMR 0.1'
PACKAGE_TARNAME='omr'
PACKAGE_URL=''
PACKAGE_VERSION='0.1'
PATH_SEPARATOR=':'
SHELL='/bin/sh'
SPEC=''
ac_ct_CC=''
ac_ct_CXX=''
arlibext='.a'
bindir='${exec_prefix}/bin'
build='i370-ibm-openedition'
build_alias=''
build_cpu='i370'
build_os='openedition'
build_vendor='ibm'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
enable_DDR='no'
enable_fvtest='no'
enable_fvtest_agent='no'
enable_tracegen='yes'
exe_output_dir='$(top_srcdir)'
exec_prefix='${prefix}'
exeext=''
host='i370-ibm-openedition'
host_alias=''
host_cpu='i370'
host_os='openedition'
host_vendor='ibm'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
lib_output_dir='$(top_srcdir)/lib'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
libprefix='lib'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
objext='.o'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/usr/local'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
solibext='.so'
sysconfdir='${prefix}/etc'
target_alias=''

## ------------------- ##
## File substitutions. ##
## ------------------- ##

OMR_JIT_VERSION_STRING='./OMR_JIT_VERSION_STRING'
OMR_VERSION_STRING='./OMR_VERSION_STRING'

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "OMR"
#define PACKAGE_TARNAME "omr"
#define PACKAGE_VERSION "0.1"
#define PACKAGE_STRING "OMR 0.1"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define SIZEOF_VOID_P 4
#define OMR_GC 1
#define OMR_PORT 1
#define OMR_THREAD 1
#define OMR_OMRSIG 1
#define OMR_GC_ALLOCATION_TAX 1
#define OMR_GC_ARRAYLETS 1
#define OMR_GC_BATCH_CLEAR_TLH 1
#define OMR_GC_COMBINATION_SPEC 1
#define OMR_GC_DEBUG_ASSERTS 1
#define OMR_GC_HEAP_CARD_TABLE 1
#define OMR_GC_LARGE_OBJECT_AREA 1
#define OMR_GC_MINIMUM_OBJECT_SIZE 1
#define OMR_GC_MODRON_STANDARD 1
#define OMR_GC_NON_ZERO_TLH 1
#define OMR_GC_THREAD_LOCAL_HEAP 1
#define OMR_INTERP_HAS_SEMAPHORES 1
#define OMR_RAS_TDF_TRACE 1
#define OMR_THR_ADAPTIVE_SPIN 1
#define OMR_THR_JLM 1
#define OMR_THR_JLM_HOLD_TIMES 1
#define OMR_THR_LOCK_NURSERY 1
#define HAVE_NUMA_H 1
#define OMRTHREAD_LIB_ZOS 1

[mgaudet]

Hmm.

So looking at our internal builds, we use run_configure.mk, like this:

make run_configure.mk SPEC=zos_390-64 OMRGLUE=example/glue

and then run make.

Want to give that a try and let me know what happens? If it doesn't work, we'll try to sort out the configuration differences at the root.

Really appreciate you taking the time to try to make this work though!

[daveyc]

I'm using Rockets gmake port which I wouldn't expect to be a problem but your solution doesn't work.

DOC:/u/doc/omr: >make run_configure.mk SPEC=zos_390-64 OMRGLUE=example/glue
gmake: `run_configure.mk' is up to date.

[daveyc]

It seems to me that there has been a lot of work put into making the makefiles work on z/OS. I'm more than happy to help getting this to work but I can't fathom why it doesn't based upon how comprehensive the z/OS makefile code seems to be.

[mgaudet]

Whoops! Mea-culpa. That was a typo on my part: Missed -f

make -f run_configure.mk SPEC=zos_390-64 OMRGLUE=example/glue

[daveyc]

DOC:/u/doc/omr: >make
gmake[1]: Entering directory `/u/doc/omr'
gmake -C util/a2e all
gmake[2]: Entering directory `/u/doc/omr/util/a2e'
c89  -I.  -DUT_DIRECT_TRACE_REGISTRATION -I../../include_core -I../../nls -I../../util/a2e/headers -DJ9ZOS390 -DLONGLONG -DJ9VM_TIERED_CODE_CACHE -D_ALL_SOURCE -D_XOPEN_SOURCE_EXTENDED -DIBM_ATOE -D_POSIX_SOURCE  -DJ9ZOS39064 -Wc,DLL,EXPORTALL  -Wc,ARCH\(7\) -O3 -Wc,TUNE\(10\) -Wc,inline\(auto,noreport,600,5000\) -Wl,compat=ZOSV1R13 -Wc,"langlvl(extc99)" -Wc,g9 -Wc,xplink,convlit\(ISO8859-1\),rostring,FLOAT\(IEEE,FOLD,AFP\),enum\(4\) -Wa,goff -Wc,NOANSIALIAS -Wc,TARGET\(zOSV1R13\) -W "c,list,offset" -Wc,lp64 -Wa,SYSPARM\(BIT64\)   -c sysTranslate.c -o sysTranslate.o > sysTranslate.asmlist
FSUM3008 Specify a file with the correct suffix (.c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -o.
gmake[2]: *** [sysTranslate.o] Error 1
gmake[2]: Leaving directory `/u/doc/omr/util/a2e'
gmake[1]: *** [util/a2e] Error 2
gmake[1]: Leaving directory `/u/doc/omr'
gmake: *** [tools] Error 2

[daveyc]

Maybe this is due to the compiler settings in the stanza.

*
* FUNCTION: z/OS 1.7 XL C/C++ Compiler Configuration file
*
* Licensed Materials - Property of IBM
* 5694-A01 (C) Copyright IBM Corp. 2004, 2005
* All Rights Reserved
* US Government Users Restricted Rights - Use, duplication or
* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
*
* C compiler, extended mode
xlc:      use               = DEFLT
          options           = -D_XOPEN_SOURCE=600, -D_UNIX03_THREADS, -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6

* XPLINK C compiler, extended mode
xlc_x:    use               = DEFLT

* 64 bit C compiler, extended mode
xlc_64:   use               = DEFLT

* C compiler, common usage C
cc:       use               = DEFLT
          options           = -D_XOPEN_SOURCE=600, -D_UNIX03_THREADS, -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6

* XPLINK C compiler, common usage C
cc_x:     use               = DEFLT

* 64 bit C compiler, common usage C
cc_64:    use               = DEFLT

* Strict ANSI C 89 compiler
c89:      use               = DEFLT

* XPLINK Strict ANSI C 89 compiler
c89_x:    use               = DEFLT

* 64 bit Strict ANSI C 89 compiler
c89_64:   use               = DEFLT

* ISO/IEC 9899:1999 Standard Compliant C Compiler
c99:      use               = DEFLT

* XPLINK ISO/IEC 9899:1999 Standard Compliant C Compiler
c99_x:    use               = DEFLT
          options           = -D_XOPEN_SOURCE=600, -D_UNIX03_THREADS, -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6, -D_POSIX_C_SOURCE=200112L


* 64 bit ISO/IEC 9899:1999 Standard Compliant C Compiler
c99_64:   use               = DEFLT

* ANSI C++ compiler
cxx:      use               = DEFLT
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* XPLINK ANSI C++ compiler
cxx_x:    use               = DEFLT
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* 64 bit ANSI C++ compiler
cxx_64:   use               = DEFLT
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* ANSI C++ compiler
c++:      use               = DEFLT
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* XPLINK ANSI C++ compiler
c++_x:    use               = DEFLT
          options           = -D_XOPEN_SOURCE=600, -D_UNIX03_THREADS, -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* 64 bit ANSI C++ compiler
c++_64:   use               = DEFLT
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* C++ compiler, extended mode
xlC:      use               = DEFLT
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* XPLINK C++ compiler, extended mode
xlC_x:    use               = DEFLT
          options           = -qlang=newexcp, -qlang=extended0x, -D_XOPEN_SOURCE=600, -D__IBMCPP_TR1__, -D_UNIX03_THREADS, -qlang=libext,  -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6, -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_EXTENDED
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* 64 bit C++ compiler, extended mode
xlC_64:   use               = DEFLT
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* C++ compiler, extended mode
xlc++:    use               = DEFLT
          options           = -qlang=newexcp, -qlang=extended0x, -D_XOPEN_SOURCE=600, -D__IBMCPP_TR1__, -D_UNIX03_THREADS, -qlang=longlong, -qlang=libext,  -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* XPLINK C++ compiler, extended mode
xlc++_x:  use               = DEFLT
          options           = -qlang=newexcp, -qlang=extended0x, -D_XOPEN_SOURCE=600, -D__IBMCPP_TR1__, -D_UNIX03_THREADS, -qlang=longlong, -qlang=libext,  -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* 64 bit C++ compiler, extended mode
xlc++_64: use               = DEFLT
          options           = -qlang=newexcp, -qlang=extended0x, -D_XOPEN_SOURCE=600, -D__IBMCPP_TR1__, -D_UNIX03_THREADS, -qlang=longlong, -qlang=libext,  -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6
          xlC               = /usr/lpp/cbclib/xlc/bin/.orig/xlC
          ipa               = /bin/cxx

* common definitions
DEFLT:    cppcomp           = /usr/lpp/cbclib/xlc/exe/ccndrvr
          ccomp             = /usr/lpp/cbclib/xlc/exe/ccndrvr
          ipacomp           = /usr/lpp/cbclib/xlc/exe/ccndrvr
          ipa               = /bin/c89
          as                = /bin/c89
          ld_c              = /bin/c89
          ld_cpp            = /bin/cxx
          xlC               = /usr/lpp/cbclib/xlc/bin/xlc
          xlCcopt           =
          options           = -D_XOPEN_SOURCE=600, -D_XOPEN_SOURCE_EXTENDED, -D__IBMCPP_TR1__, -D_UNIX03_THREADS, -D_OPEN_SYS_SOCK_EXT2, -D__OPEN_SYS_SOCK_EXT, -D_OPEN_SYS_SOCK_IPV6, -qlang=longlong
          sysobj            = sys1.cee.sceeobj:sys1.cee.sceecpp
          syslib            = sys1.cee.sceelkex:sys1.cee.sceelked:sys1.cbc.sccnobj:sys1.csslib
          syslib_x          = sys1.cee.sceebnd2:sys1.cbc.sccnobj:sys1.csslib
          exportlist_c      = NONE
          exportlist_cpp    = sys1.cee.sceelib(c128n):sys1.cbc.sclbsid(iostream,complex)
          exportlist_c_x    = sys1.cee.sceelib(celhs003,celhs001)
          exportlist_cpp_x  = sys1.cee.sceelib(celhs003,celhs001,celhscpp,c128):sys1.cbc.sclbsid(iostream,complex)
          exportlist_c_64   = sys1.cee.sceelib(celqs003)
          exportlist_cpp_64 = sys1.cee.sceelib(celqs003,celqscpp,c64):sys1.cbc.sclbsid(iosx64)
          steplib           = CICS.V690.CICS.SDFHLOAD
          cxxsuffix         = cpp
          osuffix_host      = OBJECT

[daveyc]

BTW, it got worse with your last suggestion. Before it compiled but wouldn't link.

[mgaudet]

Hmm.

I think I'll need to tap in some assistance from some people who know z/OS + OMR build better than I. Lemme try to find someone!

[fjeremic]

@daveyc what xlC version are you on? The one we use in production is z/OS V2.1.1 XL C/C++ on z/OS V2R1. Here is the first line of my make command after configuring:

cc  -I.  -DUT_DIRECT_TRACE_REGISTRATION -I../../include_core -I../../nls -I../../util/a2e/headers -DJ9ZOS390 -DLONGLONG -DJ9VM_TIERED_CODE_CACHE -D_ALL_SOURCE -D_XOPEN_SOURCE_EXTENDED -DIBM_ATOE -D_POSIX_SOURCE  -D_LARGE_FILES -Wc,DLL,EXPORTALL  -Wc,ARCH\(7\) -O3 -Wc,TUNE\(10\) -Wc,inline\(auto,noreport,600,5000\) -Wl,compat=ZOSV1R13 -Wc,"langlvl(extc99)" -Wc,g9 -Wc,xplink,convlit\(ISO8859-1\),rostring,FLOAT\(IEEE,FOLD,AFP\),enum\(4\) -Wa,goff -Wc,NOANSIALIAS -Wc,TARGET\(zOSV1R13\) -W "c,list,offset"   -c sysTranslate.c -o sysTranslate.o > sysTranslate.asmlist
WARNING CCN0049 ./sysTranslate.c:0     The option "G9" is not supported.

It looks like for you it is invoking c89.

[daveyc]

@fjeremic I'm using XL C/C++ 2.2 on a z/OS 2.2 system. Let's back up to the original problem which was the link not working. The c89 issue only occurs when I used the suggestion by @mgaudet to use make -f run_configure.mk SPEC=zos_390-64 OMRGLUE=example/glue which doesn't work. If I run ./configure && make the first line of my make is the same as yours, which works.

cc  -I.  -DUT_DIRECT_TRACE_REGISTRATION -I../../include_core -I../../nls -I../../util/a2e/headers -DJ9ZOS390 -DLONGLONG -DJ9VM_TIERED_CODE_CACHE -D_ALL_SOURCE -D_XOPEN_SOURCE_EXTENDED -DIBM_ATOE -D_POSIX_SOURCE  -D_LARGE_FILES -Wc,DLL,EXPORTALL  -Wc,ARCH\(7\) -O3 -Wc,TUNE\(10\) -Wc,inline\(auto,noreport,600,5000\) -Wl,compat=ZOSV1R13 -Wc,"langlvl(extc99)" -Wc,g9 -Wc,xplink,convlit\(ISO8859-1\),rostring,FLOAT\(IEEE,FOLD,AFP\),enum\(4\) -Wa,goff -Wc,NOANSIALIAS -Wc,TARGET\(zOSV1R13\) -W "c,list,offset"   -c sysTranslate.c -o sysTranslate.o > sysTranslate.asmlist
WARNING CCN0049 ./sysTranslate.c:0     The option "G9" is not supported.

But the link fails, as per the original issue.

xlC_x -Wc,"langlvl(extended)" -+  -o ../../hookgen HookGen.o main.o pugixml.o      -L. -L../.. -L../../lib  ../../lib/libj9a2e.x -Wl,xplink
FSUM3010 Specify a file with the correct suffix (.C, .hh, .i, .c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -L..

I can fix it by modifying the command but that's going to get tedious for the entire build.

xlC_x -Wc,"langlvl(extended)" -+ -Wl,xplink -L. -L../.. -L../../lib -o ../../hookgen HookGen.o main.o pugixml.o ../../lib/libj9a2e.x

[daveyc]

I fixed the link error using a filthy hack in /omrmakefiles/rules.zos.mk

 define LINK_CXX_EXE_COMMAND
-$(CXXLINKEXE) $(OMR_MK_CXXLINKFLAGS) -o $@ \
-  $(OBJECTS) \
-  $(LDFLAGS) $(MODULE_LDFLAGS) $(GLOBAL_LDFLAGS)
+$(CXXLINKEXE) $(OMR_MK_CXXLINKFLAGS) $(LDFLAGS) -o $@ $(OBJECTS) ../../lib/libj9a2e.x
 endef

Then it failed due to a missing shared library.

gmake[1]: Entering directory '/u/doc/omr' cd . && ./hookgen /u/doc/omr/gc/base/omrmmprivate.hdf EDC5205S DLL module not found. (errno2=0xC40B0025) iconv_init: libwrappers.so not found

I found libwrappers.so in /usr/lpp/java/J8.0/lib/s390 so I added that to my LIBPATH.

Now it fails running the hookgen command. I'm not sure why as the output is in ASCII.

cd . && ./hookgen /u/doc/omr/gc/base/omrmmprivate.hdf ▒▒▒?ʀ▒▒?/▒▒>ŀ▒ˎGNUmakefile:238: recipe for target '/u/doc/omr/gc/base/omrmmprivate.sentinel' failed gmake[1]: *** [/u/doc/omr/gc/base/omrmmprivate.sentinel] Error 255

[charliegracie]

Hi, I was unavailable for a few days and missed this thread. Are you trying to build a 31 or 64 bit version of OMR? Our autotools story has not been extensively tested on zOS outside of our normal build process. If you try one of my configure lines below make sure to run make clean first and I might also start with a fresh clone just to make sure no configuration is left over from the previous tests.

Here is the configure line I would use for 64 bit:
sh configure --disable-auto-build-flag 'OMRGLUE=example/glue' 'SPEC=zos_390-64' --enable-OMR_EXAMPLE --enable-OMR_GC --enable-OMR_PORT --enable-OMR_THREAD --enable-OMR_OMRSIG --enable-fvtest --enable-OMR_GC_SEGREGATED_HEAP --enable-OMR_GC_MODRON_SCAVENGER --enable-OMR_GC_MODRON_CONCURRENT_MARK --enable-OMR_THR_CUSTOM_SPIN_OPTIONS --enable-OMR_NOTIFY_POLICY_CONTROL --enable-OMR_THR_THREE_TIER_LOCKING --enable-OMRTHREAD_LIB_ZOS --enable-OMR_ARCH_S390 --enable-OMR_ENV_DATA64 --enable-OMR_GC_ARRAYLETS --enable-OMR_PORT_CAN_RESERVE_SPECIFIC_ADDRESS libprefix=lib exeext= solibext=.so arlibext=.a objext=.o 'AS=c89' 'CC=c89' 'CXX=cxx' 'CCLINKEXE=$(CC)' 'CCLINKSHARED=cc' 'CXXLINKEXE=cxx' 'CXXLINKSHARED=cxx' 'AR=ar' 'OMR_HOST_OS=zos' 'OMR_HOST_ARCH=s390' 'OMR_TARGET_DATASIZE=64' 'OMR_TOOLCHAIN=xlc'

Here is the configure line I would use for 31 bit:
sh configure --disable-auto-build-flag 'OMRGLUE=example/glue' 'SPEC=zos_390' --enable-OMR_EXAMPLE --enable-OMR_GC --enable-OMR_PORT --enable-OMR_THREAD --enable-OMR_OMRSIG --enable-fvtest --enable-OMR_GC_SEGREGATED_HEAP --enable-OMR_GC_MODRON_SCAVENGER --enable-OMR_GC_MODRON_CONCURRENT_MARK --enable-OMR_THR_CUSTOM_SPIN_OPTIONS --enable-OMR_NOTIFY_POLICY_CONTROL --enable-OMR_THR_THREE_TIER_LOCKING --enable-OMRTHREAD_LIB_ZOS --enable-OMR_ARCH_S390 --enable-OMR_PORT_ZOS_CEEHDLRSUPPORT --enable-OMR_GC_ARRAYLETS --enable-OMR_PORT_CAN_RESERVE_SPECIFIC_ADDRESS libprefix=lib exeext= solibext=.so arlibext=.a objext=.o 'AS=c89' 'CC=c89' 'CXX=cxx' 'CCLINKEXE=$(CC)' 'CCLINKSHARED=cc' 'CXXLINKEXE=cxx' 'CXXLINKSHARED=cxx' 'AR=ar' 'OMR_HOST_OS=zos' 'OMR_HOST_ARCH=s390' 'OMR_TARGET_DATASIZE=31' 'OMR_TOOLCHAIN=xlc'

[charliegracie]

Here is my output from configure using the above 31 bit command line:

checking build system type... i370-ibm-openedition
checking host system type... i370-ibm-openedition
checking OMR_HOST_OS... zos
checking OMR_HOST_ARCH... s390
checking for gcc... c89
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether c89 accepts -g... yes
checking for c89 option to accept ISO C89... none needed
checking how to run the C preprocessor... c89 -E
checking for grep that handles long lines and -e... /home/j9build/bin//grep
checking for egrep... /home/j9build/bin//grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking OMR_TARGET_DATASIZE... 31
checking OMR_TOOLCHAIN... xlc
checking for gcc... (cached) c89
checking whether we are using the GNU C compiler... (cached) no
checking whether c89 accepts -g... (cached) yes
checking for c89 option to accept ISO C89... (cached) none needed
checking whether we are using the GNU C++ compiler... no
checking whether cxx accepts -g... no
checking for numa.h... yes
checking for ./OMR_VERSION_STRING... no
checking for ./OMR_JIT_VERSION_STRING... no
configure: creating ./config.status
trap: ./config.status 582: FSUM7327 signal number 13 not conventional
config.status: creating include_core/omrversionstrings.h
config.status: creating omrmakefiles/configure.mk
config.status: creating omr.rc
config.status: creating include_core/omrcfg.h
config.status: executing toolconfigure commands
trap: ./configure 1966: FSUM7327 signal number 13 not conventional
checking build system type... i370-ibm-openedition
checking OMR_BUILD_OS... zos
checking OMR_BUILD_ARCH... s390
checking for gcc... c89
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether c89 accepts -g... yes
checking for c89 option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... no
checking whether cxx accepts -g... no
checking how to run the C preprocessor... c89 -E
checking for grep that handles long lines and -e... /home/j9build/bin//grep
checking for egrep... /home/j9build/bin//grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking size of void *... 4
checking OMR_BUILD_DATASIZE... 32
checking OMR_BUILD_TOOLCHAIN... xlc
configure: creating ./config.status
trap: ./config.status 567: FSUM7327 signal number 13 not conventional
config.status: creating toolconfigure.mk
config.status: creating toolconfig.h

[daveyc]

Hi @charliegracie. Thanks for your help here. I want to build both 31 and 64 bit. I tried your configure but unfortunately it failed on the first compile.

c89 -I. -DUT_DIRECT_TRACE_REGISTRATION -I../../include_core -I../../nls -I../../util/a2e/headers -DJ9ZOS390 -DLONGLONG -DJ9VM_TIERED_CODE_CACHE -D_ALL_SOURCE -D_XOPEN_SOURCE_EXTENDED -DIBM_ATOE -D_POSIX_SOURCE -D_LARGE_FILES -Wc,DLL,EXPORTALL -Wc,ARCH\(7\) -O3 -Wc,TUNE\(10\) -Wc,inline\(auto,noreport,600,5000\) -Wl,compat=ZOSV1R13 -Wc,"langlvl(extc99)" -Wc,g9 -Wc,xplink,convlit\(ISO8859-1\),rostring,FLOAT\(IEEE,FOLD,AFP\),enum\(4\) -Wa,goff -Wc,NOANSIALIAS -Wc,TARGET\(zOSV1R13\) -W "c,list,offset" -c sysTranslate.c -o sysTranslate.o > sysTranslate.asmlist FSUM3008 Specify a file with the correct suffix (.c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -o. ../../omrmakefiles/rules.mk:364: recipe for target 'sysTranslate.o' failed
If I change c89 to cc it compiles but fails on the link. It's puzzling to why it works for you but fails for me. I've already posted the stanza I'm using so maybe my configuration is causing this issue?

I'm happy to keep trying this until we fix it but in the meantime if you have a z/OS build is there any chance of sending me a tarball so I can start using it? We've got a comprehensive port of Lua with many libraries here and I want to try out the lua-vermelha project by @Leonardo2718. It it seems promising I would like to contribute to that project to make it production ready.

[daveyc]

I've got a suspicion that your toolchain at IBM is customized to support Linux like compiler syntax that the unwashed masses don't have. Maybe it's an unpublished environment variable?

[mgaudet]

According to the XLC Info centre:

The c89 command can also process files which do not match any of the above forms. By setting the environment variable {_EXTRA_ARGS} to a value of 1, such files will be processed during link-editing. The c89 command will use information in addition to the suffix of the file to determine that the file is to be processed as an object file or as a library.

Feel like a bit of a long shot, but... want to try it?

[daveyc]

Setting export _C89_CCMODE=1 fixed that problem but now I get:
````
cd . && ./hookgen /u/doc/omr/gc/base/omrmmprivate.hdf
Error 11 loading /u/doc/omr/gc/base/omrmmprivate.hdf
GNUmakefile:238: recipe for target '/u/doc/omr/gc/base/omrmmprivate.sentinel' failed
gmake[1]: * [/u/doc/omr/gc/base/omrmmprivate.sentinel] Error 255

````

[daveyc]

The lesson learned here is I need to export _xxx_CCMODE=1 for all compilers.

[mgaudet]

Huh! I'd never seen that env var before. For future reference, here's the documentation in a tech note.

To be clear, did

     export _CC_CCMODE=1
    export _CXX_CCMODE=1
    export _C89_CCMODE=1

work?

[daveyc]

To be clear by xxx I meant CC, CXX, C89 etc where xxx is the compiler.

I suspect EBCDIC issues going on here. I use Rocket softwares Git port. The XML files are in ASCII and if there are some kind of conversions going on it may break.

[fjeremic]

Lo and behold yes you are correct. Had this in my profile for years and years:

:>env | grep CCMODE
23:_CXX_CCMODE=1
37:_CC_CCMODE=1
56:_C89_CCMODE=1

We need to update our configure script to add these in as we definitely rely on them.

[daveyc]

We're making progress towards a readme.ZOS

[mgaudet]

:D

So current status is that you can build, but you run into the ASCII/EBCDIC problems with hookgen mentioned in your earlier comment?

[daveyc]

Correct. I think the builds are good but hookgen fails parsing the /omr/gc/base/omrmmprivate.hdf file. Like I said I suspect it's brain-damaged EBCDIC. But I could be wrong. Do you guys use Rockets Git port? It uses file tagging for ASCII files.

[mgaudet]

_(Someone else needs to correct me on this)_

I don't believe so -- we've investigated it, but haven't yet flipped the switch. So we've been cloning on ascii systems, then running an a2e script to produce an EBCDIC archive.

Gonna get a clearer answer for you.

[daveyc]

a2e may be the problem. Rocket use enhanced ASCII for their Git port. If the XML is expected to be in EBCDIC then that is a big fly in the ointment.

[daveyc]

But it can be solved with a .gitattributes file for z/OS.

[fjeremic]

Do you guys use Rockets Git port?

Unfortunately no, due to licensing concerns I believe. For builds on z/OS we have been cloning on Linux and doing an scp over to z/OS which also automatically does the ASCII to EBCDIC conversion.

[daveyc]

I really would encourage you guys to use Rockets Git port. I don't think there are any license issues as it's free to use and IBM devops tools are pushing it's development. Most z/OS vendors have jumped right on it.

[daveyc]

So I think we have a good reason why the build is failing. A script that converts ASCII files to EBCDIC should fix it. What files are expected to be in EBCDIC?

[daveyc]

Maybe we should start a omr-zos branch so we can work on this?

[fjeremic]

/omr/gc/base/omrmmprivate.hdf

This file is supposed to be EBCDIC. I just checked the file on one of our build machines and it is readable as an XML file on z/OS. Did git clone this file as ASCII on your system?

[mgaudet]

@daveyc Just to help us be clear, because you're using the tagging system, you've got the following env vars set?

export _BPXK_AUTOCVT=ON
export _CEE_RUNOPTS="POSIX(ON),FILETAG(AUTOCVT,AUTOTAG)"

(I don't think we normally do, so I'm just trying to make sure we enumerate the differences here).

I'm wondering if there's actually some sort of double conversion happening here.

[daveyc]

Rockets Git port uses enhanced ASCII so files are tagged in either ISO8859-1 or IBM-1047. It's critical to how z/OS Git works. If a file is EBCDIC it needs to be in .gitattributes to specify that it's EBCDIC. Have a look here

[daveyc]

@mgaudet I think you are quite right that double conversion is the problem. I was trying to make that point but probably didn't articulate it properly.

[mgaudet]

Ok: to summarized my current understanding: because our build (_why! why!?_) expects mixed-mode -- i.e. some files (xml) ASCII and others EBCDIC -- we absolutely need to have a .gitattribues.

Based on the manual a .gitattributes similar to

*     working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.xml working-tree-encoding=iso8859-1 git-encoding=iso8859-1

May suffice.

[daveyc]

My current understanding is that your build won't work using Rockets git port! If I downloaded a tarball from github it may work but then I can't contribute :(

[mgaudet]

(This issue will almost certainly bite https://github.com/eclipse/openj9 as well)

[mgaudet]

Long term, I definitely want to get working with the Rocket port. In the mean time though, can we verify that you're able to build with a copy zipped and scp'd? I just don't want this to block of from ironing out the rest of your issues.

I think I will open a separate issue for providing the .gitattributes.

[daveyc]

Can you send me a pre-built tarball?

[daveyc]

And I really do think it's a good idea to start a omr-zos branch.

[zorts]

@fjeremic : you mentioned in an earlier comment that you're not using the Rocket git port "due to licensing concerns I believe."

What might those be? Rocket passes along the license of the underlying tool, we don't assert any other licensing rights. Feel free to download!

[fjeremic]

What might those be? Rocket passes along the license of the underlying tool, we don't assert any other licensing rights. Feel free to download!

I think it may be historical and obsolete. Since seeing @daveyc's comment I've circled back started the process to get Rocket git port installed on our z/OS build systems. Once this is done we can start with a clean image without any environment settings and work out the kinks in our z/OS clone, configure, and build steps.

And of course this will be a great opportunity to simplify some of our internal builds on z/OS using these iconv and scp heroics requiring multiple machines to get a z/OS build going.

Maybe we should start a omr-zos branch so we can work on this?

I don't see a reason why this work cannot be done in master. Once we have a clean image and tooling setup we can resolve these issues, however if you are up for it (and we welcome you with open arms) you can also submit a PR to solve the _CCMODE configuration issue 😃

[daveyc]

Rockets z/OS Git port is a game changer. The most significant open source port for z/OS in the last decade. As I mentioned earlier IBM are building z/OS CI tools like IBM Dependency Based Build that depend on it.

IMO, you should aim to make this an ASCII build and banish EBCDIC to the depths of hell where it belongs! File tagging works well even in traditional EBCDIC environments like ISPF.

I'll start an INSTALL.ZOS using the information in this thread.

This is exciting technology. I'm aware of the rubyomr technology preview. Rocket have Python, Perl and PHP z/OS ports, we use Lua. Any work done to JIT enable those languages can be ported to z/OS where CPU consumption costs big $$$.

[daveyc]

Progress! I've got a clean build. Converting the *.hdf and *.tdf files to EBCDIC worked. The build is excruciatingly slow. Definitely one to let simmer overnight 😄

Unfortunately, the test failed with an 0C4 abend in GCConfigTest::TearDown.

It crashes line 177 cli->kill(env); cli is NULL so it's pointing to low core.

````
Abend Code. . . . . . . . . : S0C4-X'4'
Program-Interruption Code . : 0004 (Protection Exception)
An attempt was made to reference main storage that was not available in the
configuration.

NOTE: Source code information could not be presented due to insufficient
information available to Fault Analyzer.

Load Module Name. . . . . . : ./(omrgctest)
At Address. . . . . . . . : 22C82000

Entry Point Name. . . . . . : GCConfigTest::TearDown()
At Address. . . . . . . . : 22C97988 (Module omrgctest offset X'15988')

Machine Instruction . . . . : 58306010 L R3,16(,R6)
At Address. . . . . . . . : 22C97BF4 (Entry point GCConfigTest::TearDown()
offset X'26C')
AMODE . . . . . . . . . . : 31
Failing Operand . . . . . : Second operand (Addressing exception)
First Operand (R3). . . . : 00000000
Second Operand Address. . : 000A0010 (Storage invalid)
Second Operand Length . . : 4

Instructions around point of failure:

Offset Hex Instruction
-2A 5880 4AF4 L R8,2804(,R4)
-26 5870 D1C0 L R7,448(,R13)
-22 181D LR R1,R13
-20 1826 LR R2,R6
-1E 5860 7014 L R6,20(,R7)
-1A 5850 7010 L R5,16(,R7)
-16 0D76 BASR R7,R6
-14 4700 FFB3 BC 0,4019(,R15)
-10 50A0 9124 ST R10,292(,R9)
-C 5870 9014 L R7,20(,R9)
-8 5820 9010 L R2,16(,R9)
-4 5860 7000 L R6,0(,R7)
22C97BF4 5830 6010 L R3,16(,R6)
[phone] L R1,20(,R6)
[phone] L R6,20(,R3)
+C 5850 3010 L R5,16(,R3)
[phone] LA R1,0(R1,R7)
+14 0D76 BASR R7,R6
+16 4700 FFAE BC 0,4014(,R15)
+1A 5870 900C L R7,12(,R9)
``` Thecli` object is created by a factory function and there is a test for NULL which suggests is been clobbered.

000076 /* Instantiate collector interface */ 000077 env = MM_EnvironmentBase::getEnvironment(exampleVM->_omrVMThread); 000078 cli = startupManager.createCollectorLanguageInterface(env); 000079 if (NULL == cli) { 000080 FAIL() << "Failed to instantiate collector interface."; 000081 } 000082

[fjeremic]

@daveyc was a production or debug build? We have certainly encountered xlC issues in the past with OMR libraries and had to apply specific workarounds or patches to address the issues. I'm wondering if we are perhaps hitting one of those for this failed test. @charliegracie does this look familiar at all?

Would it be possible to try via a debug build? @charliegracie I forget, how is this done again exactly? I recall some flavor of OMR_DEBUG=1 export or something like that. We should document this. I see

--enable-optimized      Create an optimized build. (Default: yes)

In the ./configure --help but there doesn't seem to be a way to disable.

[daveyc]

@rjeremic It's a production build. If this is a xlC compiler bug then that's a serious defect and we should open a PMR with the compiler folks ASAP!

[charliegracie]

That does not look like anything I am aware of.
To enable a debug build if you are invoking configure directly you can add --disable-optimized. If you are invoking the run_configure.mk that @mgaudet mentioned you would add the following option EXTRA_CONFIGURE_ARGS=--disable-optimized

[charliegracie]

The bug is likely a missing assert / NULL check in the teardown. I bet it is related to ASCII files attempting to be read so the test fails early in setup trying to read the file. The GC test uses a bunch of XML files from this folder omr/fvtest/gctest/configuration to drive the testing. I do not have access to a z/OS machine right now to check to see if they are in ASCII or EBCIDIC but I would assume they are supposed to be in EBCIDIC.

[charliegracie]

On the ASCII vs EBCDIC I would love to completely remove all notion of EBCDIC from the project. I personally do not have enough experience on zOS to do this quickly but I would definitely support any effort going in this direction.

[daveyc]

I converted the *.hdf and *.tdf files from ASCII to EBCDIC using the following command:

for a in $(find . -name "*.[th]df"); do iconv -f iso8859-1 -t ibm-1047 $a > $a.new ; mv $a.new $a ; chtag -tc IBM-1047 $a; done
Are there any other files that may have encoding issues?

[daveyc]

@charliegracie removing EBCDIC isn't that difficult. First cab of the rank is installing Rockets git port on your z/OS machines which I believe is in progress.

[fjeremic]

@daveyc FYI some time later but better late than never. As part of #3693 we've converted the entire OMR build system to use CMake [1]. The ASCII/EBCDIC issues discussed above are now largely moot. Unfortunately we'll need to keep them around for a little longer until the downstream dependencies are broken and only then we can get rid of all those #include "atoe.h" workarounds.

[1] https://github.com/fjeremic/CMake/

[fjeremic]

I think we can safely close this issue now. With the migration to CMake for z/OS configuration and builds this is no longer an issue since the required variables are set in the build system. Closing this. Feel free to reopen if there are further issues.