I compiled a software (GROMACS 2016.3) using cmake (3.5.1) with the following flags:
cmake .. -DGMX_BUILD_OWN_FFTW=ON -DREGRESSIONTEST_DOWNLOAD=ON -DGMX_MPI=on -DGMX_GPU=on -DGMX_OPENMP=on -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda-8.0 -DGPU_DEPLOYMENT_KIT_ROOT_DIR=/usr/local/cuda-8.0
CUDA libraries 8.0 were installed from deb with the default paths.
When the software runs it throws a warning as GROMACS was configured without NVML support ... Recompile with the NVML library.
How can I make it see such library? Am I giving the wrong paths to cmake? (No warnings or errors arise when compiling gromacs).
Many thanks
I am currently compiling GROMACS to support NVML as well, and here is how I got it to work: add this to your cmake, substitute your paths as needed.
-DNVML_INCLUDE_DIR=/usr/cuda_toolkit/8.0.61/include -DNVML_LIBRARY=/usr/cuda_toolkit/8.0.61/lib64/stubs/libnvidia-ml.so
NVML is included as of CUDA 8+, no longer a separate install.
Related
I tried almost a hundred things to make this works but nothing seems to be working.
I recently acquire a Mac book pro M1 MAX (so arm64 architecture), system provided by default with clang g++.
I wanted to install boost library. Using homebrew the 1.80 version was installed but I need to work on a project with the 1.65.1 version (I tried compiling my project with 1.80 version and tons of undefined symbols and errors were raised from boost library even if I have all of them, so I'm guessing I need to install the exact same version required)
so I decided to build and compile boost by myself following the boost guide
https://www.boost.org/doc/libs/1_65_1/more/getting_started/unix-variants.html
Following section 5.1 I tried to use the bootstrap script and this one fails using Darwin toolset. (apparently some Clang warning caused error). I resolve then by changing the boost source code like this :
https://github.com/boostorg/build/commit/48e9017139dd94446633480661e5447c7e0d8b1b
But there's still lot of issues during the compilation
I don't know what to do to be able to compile with clang, I don't even know if this will be compiled for arm64 architecture.
anyway I install gcc compiler and tried with gcc toolset.
./bootstrap --with-toolset=gcc
The bootstraps works but then running the b2 script cause a segmentation fault instantly and on every commands I tried (even the --help options raised an exception...).
Why is building boost so complicated on arm chipset ?
What can I do to build boost (either clang or gcc, arm or cross compiled universal library) ?
I'm desperate at this point.
Thanks for the help.
I tried everything
with clang (darwin)
with gcc
with options to add arm64 as architecture
changing the source code of boost to fix
I have both CUDA versions 7.5 and 8.0 installed but cmake seems to only be able to find the 7.5 version. Running this code:
find_package(CUDA 8.0 REQUIRED)
Gives this error:
CMake Error at P:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find CUDA: Found unsuitable version "7.5", but required is at
least "8.0" (found C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.5)
Even though v8.0 is in the same directory as v7.5. Is this a problem with cmake, or am I doing something wrong here?
No matter how many CUDA toolkits you have installed find_package(CUDA) finds the one that has its nvcc (typically located in <CUDA root dir>/bin) in the environment variable $PATH. If there are several nvcc in $PATH, it will pick up the first one. On windows, installer typically adds relevant environment variables automatically, so the version found depends on the order of installation.
You should not be using find_package(CUDA) anymore as CMake now has first-class support for CUDA.
For details check:
CMake documentation for FindCUDA
First few paragraphs of the header comment in Modules/FindCUDA.cmake
What are PATH and other environment variables, and how can I set or use them?
You could feed CMake with the path to CUDA explicitly, by setting the CUDA_TOOLKIT_ROOT_DIR flag from CMake command line:
cmake -DCUDA_TOOLKIT_ROOT_DIR=<path-to-cuda-8.0>.
CUDA version detection is done by CMake's findCUDA function:
https://cmake.org/cmake/help/v3.0/module/FindCUDA.html
It's possible that for some reason, findCUDA search fails to locate CUDA 8.0 you have installed.
It might be that CUDA_BIN_PATH is set to 7.5, and therefore CMake picks that.
Using the How To Build GCC 4.8.2 ARM Cross-Compiler, I have installed and setup everything and it works just fine as mentioned in the post i.e., I was able to cross compile a simple C code. But, when I try to compile a simple GMP code, I get this error.
fatal error: gmp.h: No such file or directory
Compilation terminated
How should I fix this? My goal is to compile a gmp program. If possible, refer me to good tutorials.
Thanks!
If you want GMP compiled for the target system (ARM), you must compile it by itself using the newly built cross-compiler, not as a part of building GCC. GMP (along with MPFR, MPC, ISL, CLooG, etc.) being placed in the GCC toplevel source directory simply means that it gets compiled and linked for the cross-compiler you're building.
Since the cross-compiler will run on the host system, GMP will also be compiled for the host system, else linking the library would fail, and you wouldn't get a cross-compiler. It may sound silly, but there are reasons for doing it this way, such as buggy prebuilt packages provided by the package manager on the host system or merely to avoid installing those libraries on the host system when all you want is the cross-compilation toolchain.
I'm trying to compile Pyaudio, (a Python module) from source, since I'm using Windows, and only 32-bit binaries are available - I need 64. Following these instructions I downloaded Cygwin, and installed every component, to be safe. Installing Portaudio, another module, is required first.
When I run CFLAGS="-mno-cygwin" LDFLAGS="-mno-cygwin" ./configure, I get the error configure: error: C compiler cannot create executables. See 'config.log' for more details. config.log has an additional line below that message: gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.
This leads me to believe that perhaps Cygwin is using the wrong compiler; the instructions are for using MinGw with Cygwin, but I never specified minigw in the process. I also wonder if there's something in the PyAudio build files that needs to be changed for 64-bit. I know nothing about C, compiling, Cygwin or MinGW, and am new to programming in general. Any ideas? Any other information I can provide?
Current versions of Cygwin gcc do not support -mno-cygwin anymore because it never really worked correctly. Instead, you should use a proper cross-compiler, which is provided by the mingw64-i686-gcc packages, then run ./configure --host=i686-w64-mingw32.
In some cases it is an antivirus that is causing problems.
I had avast and had to disable it.
I want to compile a source code, but there are some compiling errors about __sync_xxx functions (__sync_bool_compare_and_swap etc.)
GCC version on machine is 3.4.3 (it must be gcc 4.1 or over for supporting atomic builtins), so I have downloaded GCC v4.6, copied it to another directory (I didn't remove v3.4.3) then change the $PATH path for GCC but it doesn't work (the same error occurs).
I want to ask that is only changing gcc path with export PATH=... enough for compiling with new GCC?
Use the following configure option when compiling gcc:
--program-prefix=foo --program-suffix=bar
and it will produce bin programs of the form "foo-gcc-bar", so that you may differentiate different builds of gcc.
Replace foo and/or bar with an appropriate "tag" for your build (eg "-4.6" for example).
This way if it doesn't find your toolchain correctly it will fail fast rather than using the 3.4 version.
It also means that different toolchain builds can coexist in the standard installation prefix directories.
We have to use -march=686 switch to get it to work on intel.
Try checking and updating LD_LIBRARY_PATH, to use the lib path for the new gcc installed.