-
Notifications
You must be signed in to change notification settings - Fork 6
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
ADIOS2 CMake Error on s390x #15
Comments
@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? |
Can certainly try. Independent of that, can we potentially transform the |
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. |
@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. |
@chuckatkins @eisenhauer thank you, this is great! Just a minor question with regards to ADIOS2. Assume ADIOS2 shall be build with all options I understand that dill is required for |
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? |
Sounds good, yes maybe a simple option to control the return behavior before adding 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 |
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. |
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. |
The following CMake-stage issue is reported for ADIOS 2.5.0 on s390x architecture with dill:
Full reference: https://travis-ci.com/github/openPMD/openPMD-api/jobs/319416160
Platform: Linux
s390x
on Travis-CI within aquay.io/pypa/manylinux2014_s390x
imageCompile: GCC 8.3.1, CMake 3.17.1, static build of ADIOS 2.5.0 (with this patch: ornladios/ADIOS2#1828)
Re.: openPMD/openPMD-api#717
The text was updated successfully, but these errors were encountered: