Skip to content
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

spack install with gcc@>=9 fails because of a bug nlohmann/json (fixed for >3.5) #555

Closed
hightower8083 opened this issue Aug 22, 2019 · 6 comments
Assignees
Labels
affects latest release bug install machine/system machine & HPC system specific issues third party third party libraries that are shipped and/or linked

Comments

@hightower8083
Copy link

spack install openpmd-api %gcc@9.2.0
fails at installing nlohmann/json with this.

This issue of json with gcc@>=9 was fixed, but spack's preferred version is 3.5.
When I manually set nlohmann-json version to 3.7, installation succeeds.

@ax3l ax3l self-assigned this Aug 22, 2019
@ax3l ax3l added affects latest release bug third party third party libraries that are shipped and/or linked labels Aug 22, 2019
@ax3l
Copy link
Member

ax3l commented Aug 22, 2019

Thank you for the detailed report and testing the new GCC compiler!
In your linked PR, this seams to be fixed in nlohmann-json 3.6 and newer. The problem only occurs while building its tests, which also is non-default in spack.

The following fixes address this:

@hightower8083
Copy link
Author

yeah, i had a nasty experience of playing with update-initramfs -d (-c) after kernel-update in ubuntu screwed nvidia's xorg -- decided to make a fresh start with a new system, drivers and compilers 😁

@ax3l
Copy link
Member

ax3l commented Aug 22, 2019

Excellent choice :D Don't forget to compile with -mtune=native -march=native while rebuilding everything for speed ;)
All PRs are merged now. Please update your spack sources to see it in effect and feel free to close the issue if this solves it :)

@ax3l ax3l added the machine/system machine & HPC system specific issues label Aug 22, 2019
@hightower8083
Copy link
Author

checked 👌

@hightower8083
Copy link
Author

hightower8083 commented Aug 25, 2019

by the way, @ax3l, in which context you suggest to use the flags exactly? Consider I have gcc@9.2.0 built by spack (using default ubuntu's gcc@7.4.0), should I simply add

    flags:   
      cppflags: -mtune=native -march=native
      cflags: -mtune=native -march=native

to 9.2.0 part in .spack/linux/compilers.yaml?
Will it apply such optimization to everything built with gcc@9.2.0 even outside spack (like if I do warpx from source) ? Or should I add

export CFLAGS="-mtune=native -march=native"
export CPPFLAGS="-mtune=native -march=native"

to my .bashrc?

@ax3l
Copy link
Member

ax3l commented Aug 26, 2019

Just joking a little, these flags will cause compiled binaries to be optimally tuned for the current platform it's compiling on. But you won't notice much on regular desktop applications. Adding those to spack's compilers.yaml only influences packages build with spack. If you compile outside of spack, use CFLAGS and CXXFLAGS (careful: CPPFLAGS is your pre-compiler, aka text replacements; same typo in first quote: use cxxflags instead). Yes, you can generally add this to .bashrc if you like, I usually add those manually during compile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects latest release bug install machine/system machine & HPC system specific issues third party third party libraries that are shipped and/or linked
Projects
None yet
Development

No branches or pull requests

2 participants