ADIOS2 CMake Error on s390x

[ax3l]

The following CMake-stage issue is reported for ADIOS 2.5.0 on s390x architecture with dill:

-- Disabling emulation
-- ADIOS2 ThirdParty: Configuring dill
-- Check size of void*
-- Check size of void* - done
-- Check size of long
-- Check size of long - done
-- NO CG for Processor "s390x"
-- Check if the system is big endian
-- Searching 16 bit integer
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Searching 16 bit integer - Using unsigned short
-- Check if the system is big endian - big endian
-- Disabling emulation
CMake Error at thirdparty/dill/dill/CMakeLists.txt:254 (message):
  Configure has detected no native dynamic code generation support
     for this architecture ("UNSUPPORTED"), -DDILL_MULTI_TARGET=ON 
     was not specified, and no emulation is possible (libffi library 
     not found)
     NO LIBRARY WILL BE BUILT
-- Configuring incomplete, errors occurred!

Full reference: https://travis-ci.com/github/openPMD/openPMD-api/jobs/319416160

Platform: Linux s390x on Travis-CI within a quay.io/pypa/manylinux2014_s390x image Compile: GCC 8.3.1, CMake 3.17.1, static build of ADIOS 2.5.0 (with this patch: https://github.com/ornladios/ADIOS2/pull/1828)

Re.: https://github.com/openPMD/openPMD-api/pull/717

[ax3l]

cc @eisenhauer @chuckatkins

[eisenhauer]

@ax3l can you try one of either: 1) provide libffi (as mentioned in the error above), or 2) specify -DDILL_IGNORE_NATIVE=ON to the ADIOS2 cmake line?

[ax3l]

Can certainly try. Independent of that, can we potentially transform the dill dependency-error into a message-and-disable fallback when its requirements are not met? Like we do for other dependencies that have unmet prerequisites?

[eisenhauer]

Fallback would be the goal, and it is what happens when ffs is built outside of adios. But the cmake invocations are separate then, not run through an add_subdir as the third party includes are, and @chuckatkins might be better at sorting out how best to make that happen.

[eisenhauer]

@ax3l, the recent PR #16 , should help here. We already had a mechanism to download and build libffi if you specified DILL_IGNORE_NATIVE, and that PR extended it to situations where the native architecture is unsupported. I've got an ADIOS PR in to pull that in downstream. Would you please try once it's merged? Caveat: libffi is not ours, and it still relies upon the autotool configuration package. So your environment has to have automake and autoconf for this to work.

[ax3l]

@chuckatkins @eisenhauer thank you, this is great!

Just a minor question with regards to ADIOS2. Assume ADIOS2 shall be build with all options ADIOS2_USE_... to the default (AUTO). Assume the dill-arch is unsupported, libffi cannot be found, and also not be downloaded. I understand that this is a fatal error for dill but why can the ADIOS2 build, with dill disabled, not continue? For me as a user, this is an optional feature, no?

I understand that dill is required for SST but SST itself is an optional ADIOS2 option, right? As long as ADIOS2_USE_SST is on AUTO it should just be disabled if all tries to get its dependencies right fail, I think.

[eisenhauer]

Yes, that's the way it should work, we're just not quite there. The dependency situation is messy, with SST depending directly on FFS and EVpath, EVPath depending upon FFS and ATL, FFS depending (somewhat) optionally on DILL, and DILL potentially depending upon libffi. Just getting all this to play nicely for installations, static/dynamic builds, and everything else that happens during the course of a normal build has required heroic efforts from @chuckatkins. The situation where we're trying to build on an architecture that dill doesn't support is an uncommon case, treated as a fatal error by the dill CMake, but because of the way it's included in ADIOS, that fatal error kills the ADIOS cmake. To have that not kill ADIOS cmake, the dill CMake needs to behave differently when running under ADIOS than it does when running independently, not doing a fatal error, but calling something like "return()". But DILL builds on common HPC architectures (or really, anywhere I even have a login to), so this hasn't been much of a worry before. But I'm assuming that s390x is important to you guys?

[ax3l]

Sounds good, yes maybe a simple option to control the return behavior before adding sub_directory would already be sufficient (fatal/non-fatal).

The main thing I want to be able to address is post-processing of ADIOS files in local developer environments and on emerging hardware. I am compiling for example the openPMD ADIOS1, JSON and HDF5 backends to raspberry pi's (32-bit armv7 userland) and to web assembly (wasm). On both architectures users just want simple, serial file processing, e.g. to explore files and their meta-data. Not erroring out in configure on such low-hanging targets is just tremendously helpful to ease the adoption of ADIOS2 and bringing its file support into various bindings/languages/tools for downstream folks and users. s390x is just an example of such a platform that does not need cutting-edge HPC features but can use at least ADIOS2's basic file features to interact serially with .bp files.

[eisenhauer]

There is a way to detect if a CMakefile is running at the top level or as part of a add_subdirectory() that I was already playing with. That gets me past the DILL fatal error, and strictly speakking, the EVPath functionality that is enabled by libffi (when dill isn't present) is not actually used by ADIOS2, but the EVPath build isn't really setup to deal nicely with its absence. So making this failover nicely is going to be a bit of an iterative process involving several packages and levels. Once we're past proposals we should be able to bang it out. For what it's worth, dill works well on armv7, but I suspect that ADIOS2 may fail horribly in 32-bit domains.

[ax3l]

Sounds great! As long as I can configure it I can see where compile issues appear and then can run tests on it to see how it goes for a specific use case. I am not requesting tremendous efforts to get 32bit support, but I want to make sure we are flexible enough so that community projects can explore and adopt, e.g. wasm or anything else that pops up (exotic future 64-bit ARM or RISC-V architectures, to name a few more) and can have nice tooling/integration efforts without getting stuck in the configure phase for HPC features they don't immediately need.