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

Cmake and Bilder Issue #51

Closed
piotrt75 opened this issue Jan 17, 2017 · 4 comments
Closed

Cmake and Bilder Issue #51

piotrt75 opened this issue Jan 17, 2017 · 4 comments
Assignees
Labels

Comments

@piotrt75
Copy link
Collaborator

Recently the Bilder updated Cmake to ver 3.7.x which causes me a lot of trouble - I just can't pass through cmake. The message I see in cmake is stating that it can't find fftw3 libs although the paths are defined properly - this is not happening in cmake 3.4.x (bilder downloaded on 2nd December 2016). Same machine+system (Ubuntu mate 16.04) used.

cmake_script.txt

cmake_run.txt

@mightylorenzo
Copy link
Collaborator

This seems like ANOTHER issue I was having with building on Ubuntu 16.04 (see also issue #52 ). Combined, these caused headaches. The FULL workaround to solve both issues was using bilder built CMake, and Ubuntu supplied fftw3 and hdf5. However, now that bilder has updated CMake, as you've found, it looks like we can't do this anymore!

@mightylorenzo
Copy link
Collaborator

Here is my CMake output when trying to run it for Puffin. Seems slightly different than Piotr's...

cmake-run-l.txt

@jdasmith
Copy link
Collaborator

jdasmith commented Mar 8, 2017

Thanks for this. I think one approach is certainly to force version 3.4.1 of cmake - which as you've seen can be done either on the command line or via a machinefile for ubuntu 16.04. Piotr's error in this ticket seems to be the one with FFTW not being found. We have put in the fix Lawrence saw for FFTW3 so I think that should also solve this issue.

I guess to be sure, I need to check the following:
system openmpi, bilder hdf5 1.8.18, bilder fftw-3.3.4, cmake 3.7.1
bilder openmpi, bilder hdf5 1.8.18, bilder fftw-3.3.4, cmake 3.7.1
bilder mpich, bilder hdf5 1.8.18, bilder fftw-3.3.4, cmake 3.7.1
If these are all successful (at least bilder compiles puffin) - I just mark #51 as working (doesn't mean #52 is done).
Then we need to check
system openmpi, bilder hdf5 1.8.18, bilder fftw-3.3.4, cmake 3.4.1
bilder openmpi, bilder hdf5 1.8.18, bilder fftw-3.3.4, cmake 3.4.1
bilder mpich, bilder hdf5 1.8.18, bilder fftw-3.3.4, cmake 3.4.1
and if any of them are broken, fix, or resort to
system openmpi, bilder hdf5 1.8.13, bilder fftw-3.3.4, cmake 3.7.1
bilder openmpi, bilder hdf5 1.8.13, bilder fftw-3.3.4, cmake 3.7.1
bilder mpich, bilder hdf5 1.8.13, bilder fftw-3.3.4, cmake 3.7.1
AND/OR
system openmpi, system hdf5 1.8.16 (current? - now don't see parallel hdf5 in ubuntu repo), system fftw-3.3.4, system cmake 3.7.1

This is a lot of builds, and to be confident each time we need to reboot and use a clean environment. Anyone offering to help??? :)

I seem to have started with a few of these, but bilder changes have gone in since then so hopefully all is working better now.

I'm trying to separate out what are potentially bilder issues, from issues with scimake/cmake to issues with the packages themselves. #52 looks to be an issue with the fortran libs in hdf5-1.8.18 on ubuntu16, which I believe need patching up as there were some .mod files that weren't getting where they should (At least with intel compilers). see
cp $WORK/build-intel-para/hdf5-1.8.13/par/bin/h5f_provisional.mod $WORK/build-intel-para/hdf5-1.8.13/par/bin/h5fdmpio.mod $HOME/contrib-intel-para/hdf5-1.8.13-par/include
on the Jureca intel build page at http://community.hartree.stfc.ac.uk/portal/site/FXFEL/page/4f31e679-f396-4354-b651-875aed970368

Bilder is mostly building stuff against mpich now, but should be able to switch. It could be that I was not seeing this as I let bilder provide mpich or openmpi instead

This does take us to an open question - how many versions of openMPI/mpich and of the other packages do we want to support. The fewer we choose, the easier everything is for us to maintain, but the more people will go "but that's not what I've got on my system". The more, the more test build processes we should be running to ensure these remain working.

@mightylorenzo
Copy link
Collaborator

As far as I could tell, some flags were not explicitly set in SciMake, which was causing issues in the latest versions of CMake. They may have changed some default or assumed behaviour. In particular, the flag TFP_ALLOW_LIBRARY_DUPLICATES in SciFindPackage.cmake was causing trouble. I've manually put in an explicit flag in its place, which is absolutely not the best solution for SciMake, but it works for all cases tested in Puffin. Resolved in commit 0cf7789

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants