Issue with reference to collision integrals Q11ij

[wargnierq]

Dear All,

I am currently working on the Helium Hydrogen mixture and try to compute some collision integrals (such as Q11ij). I have git pull and install Mutationpp properly, (mppequil and check air11 are working properly I can even compute some of the properties). However, I am having issues when I am trying to call of these coefficients (something in line with a reference that is not found?). I have written a small code where I am calling these coefficients.

This code has been tested by Bruno Dias with his version of Mutation and it worked, we could have the values of the collision integrals. Then, I have contacted Ruben Di Battista and when we have linked this code with the version of Mutation++ from Macports, it was working. However, when I am trying to link this code with the Library from github, it does not compile and I can't run it.

The issue is the following:

Scanning dependencies of target omega11 [ 50%] Building CXX object CMakeFiles/omega11.dir/main.cpp.o [100%] Linking CXX executable omega11 Undefined symbols for architecture x86_64: "Mutation::Transport::CollisionDB::group(std::1::basic_string<char, std::__1::char_traits, std::1::allocator > const&)", referenced from: Mutation::Transport::CollisionDB::Q11ij() in main.cpp.o Mutation::Transport::CollisionDB::Q11ii() in main.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: [omega11] Error 1 make[1]: [CMakeFiles/omega11.dir/all] Error 2 make: *** [all] Error 2

Please find the code main.cpp in attachment as well as the CMakeList.txt file to compile the code,

Yours sincerely Code He-H.zip

I have attached my code main.cpp and my CMAKE

[rdbisme]

I tried on Linux (WSL actually), and the build works.

I'll check on macOS to see if it's specific, but I feel that's a problem with you environment. Try to disable Anaconda, maybe?

[wargnierq]

Let me know with MacOs if it works

[BBArrosDias]

I ran the script on macOS. I used clang++ compiler from Anaconda Cloud. @wargnierq did you check if you used the same compiler to install m++ and the script?

[wargnierq]

Hello,

In both cases I used:

cmake version 3.17.3

and

GNU Make 3.81

To compile mutation++ and the small code

[jbscoggi]

Hi @wargnierq, as @rubendibattista said, I think this is a problem with your setup. Specifically, it would seem you likely have multiple versions M++ installed and in your path. To see which version is actually being used, you can execute the following

DYLD_PRINT_LIBRARIES=YES checkmix air_5

This will show which shared libraries are loaded on startup of the checkmix program. Make sure the directory where the libmutation++.dylib is found is the one you expect. Assuming that works, then the problem is probably related to where cmake "finds" M++. I'm sure there is a way to print the actual path of a library loaded with find_package() in CMake but I don't know off the top of my head and will let you google it. Another option is to just use a simple Makefile that you write yourself pointing to the exact libmutation++.dylib file that you want to link with. For such a simple project, this is generally my preferred option anyway, especially if you have several versions of the library installed.

[wargnierq]

Hi @jbscoggi ,

Thank you for your fast answer ! By doing the above command, at the beginning I am having the following:

dyld: loaded: <64CCBDF0-011F-3F8C-AF41-CF1E66E6164E> /opt/local/bin/checkmix dyld: loaded: <98238C41-CB23-3B66-B822-EC33C9DDEB28> /opt/local/lib/libmutation++.dylib dyld: loaded: <59A8239F-C28A-3B59-B8FA-11340DC85EDC> /usr/lib/libc++.1.dylib dyld: loaded: <001B3B7F-D02C-31D3-B961-1ED445D5A266> /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libc++abi.dylib

My libmutation++ should not be this one, it should be in /Users/quentin/Desktop/canop/lib. Would you have an example of a simple Makefile where I will specify this libmutation++.dylib by myself ?

Thank you,

Q

[jbscoggi]

Hi @wargnierq, you don't even need a makefile. Just compile your main.cpp together with the correct libmutation++.dylib file with the proper include directory for Mutation++. Something like

compile -o omega11 main.cpp /full/path/to/your/libmutation++.dylib -I /full/path/to/your/mutation++/include/dir

where you obviously replace the compile and paths with your compiler and full paths.

[wargnierq]

Hi @jbscoggi ,

After doing the following :

g++ -o omega11 main.cpp -I /Users/quentin/Desktop/canop/include/mutation++

He found mutation++.h, but not Eigen. I remember that I had this issue long time ago. Eigen is not included in Mutation++ library ?

In file included from /Users/quentin/Desktop/canop/include/mutation++/Thermodynamics.h:39, from /Users/quentin/Desktop/canop/include/mutation++/Mixture.h:33, from /Users/quentin/Desktop/canop/include/mutation++/mutation++.h:31, from main.cpp:2: /Users/quentin/Desktop/canop/include/mutation++/MultiPhaseEquilSolver.h:33:10: fatal error: Eigen/Dense: No such file or directory 33 | #include <Eigen/Dense> | ^~~~~ compilation terminated.

[jbscoggi]

Ah yes, you also need to add the include path for Eigen. It should be shipped with mutation++ in the thirdparty directory.

[wargnierq]

If I add the Eigen repository in third party, as follows,

g++ -o omega11 main.cpp -I /Users/quentin/Desktop/canop/include/mutation++ /Users/quentin/Desktop/canop/Mutationpp/thirdparty/eigen

He does not find Eigen/Dense ? whereas [...]/eigen contains Eigen/Dense

In file included from /Users/quentin/Desktop/canop/include/mutation++/Thermodynamics.h:39, from /Users/quentin/Desktop/canop/include/mutation++/Mixture.h:33, from /Users/quentin/Desktop/canop/include/mutation++/mutation++.h:31, from main.cpp:2: /Users/quentin/Desktop/canop/include/mutation++/MultiPhaseEquilSolver.h:33:10: fatal error: Eigen/Dense: No such file or directory 33 | #include <Eigen/Dense> | ^~~~~ compilation terminated.

[jbscoggi]

You have to use -I for each new directory. Also don't forget to add the M++ library to the command like I did in my example.

[rdbisme]

Ehi @jbscoggi, I sincerely discourage people to use alternative Makefile to couple with Mutation++. To build with CMake, the only thing needed is a 7 lines CMakeLists.txt that takes into account automatically all the linkage and flags stuff and folder stuff that are configured in upstream project and so it minimizes environment changes on the user side.

cmake_policy(SET CMP0048 NEW)
cmake_minimum_required(VERSION 3.0)
project(myProgram)
set(CMAKE_CXX_STANDARD 11)
find_package(mutation++ REQUIRED)
add_executable(yourprogram main.cpp)
target_link_libraries(yourprogram PUBLIC mutation++::mutation++)

The only thing needed is to point at the mutation directory

cmake -Dmutation++_DIR=/path/to/your/mutation/install/lib/cmake/mutation++ ..

However I had a session with @wargnierq. I tried to update XCode, CommandLineTools and all the related things, I deactivated conda, I checked the shell environment, but I couldn't find the culprit of the linking problem.

What I was able to isolate, tho, is that is a problem related to AppleClang, possible to Clang. If we compile with GCC10, the build goes as expected and no error is spitted out.

I still did not try on my MacBook. Did you try on yours @jbscoggi? Which macOS version are you shipping? XCode version? What are instead the versions used in the CI at the moment?

[rdbisme]

This is the CI configuration:

-- The CXX compiler identification is AppleClang 11.0.3.11030032
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode_11.7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped

while @wargnierq has XCode 12. I'll try to check on my machine.

[BBArrosDias]

@rubendibattista again, the script I provided to @wargnierq was compiled on my mac using

clang version 10.0.0 Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /anaconda3/bin

and this works.

[rdbisme]

I think this might be a problem with the new XCode by the way. @BBArrosDias are you using clang or AppleClang? They're different things. If it's AppleClang, you are probably on HighSierra, aren't you?

Moreover, you are also using anaconda. Anaconda in my own experience is the recipe for disaster for inexperience users trying to compile things that are not packaged by it. It pollutes your environment with pre-compiled stuff that breaks as soon as you go out of the walled garden provided by it and it sticks around in environment variables when you try to use other tools.

Most of the people that use this library are generally inexperienced about build systems and compiling complex C++ software with dependencies (nothing wrong about that). If you start suggesting them to hack hand-written Makefiles the support effort becomes gigantic IMHO. 😉

That said, I'll check on my laptop where I have Xcode 12 and see if it's a specific environmental issue with @wargnierq or a general problem with XCode 12.

[jbscoggi]

@rubendibattista I agree that we should only support the "preferred" method to build, but I think from a debugging point of view, it is useful to know if he can build it manually with a single command in the shell pointing directly to his fresh install. In this way, we will know if this is a problem of his system or its just mixing different versions in cmake somehow. At any rate, it sounds to me like he is building M++ using one compiler and then trying to compile his script with another compiler. If he is using the right paths, this should be the only thing that can go wrong I think.

[jbscoggi]

@wargnierq, can you do a make clean in your M++ build directory and then run make VERBOSE=1 to see which compiler is being used? You should use the same compiler to build your script.

[rdbisme]

I just tested on my machine, and it is indeed working.

cmake -Dmutation++_DIR=$(realpath ~/git/Mutationpp/install/lib/cmake/mutation++) ..
-- The C compiler identification is AppleClang 12.0.0.12000032
-- The CXX compiler identification is AppleClang 12.0.0.12000032
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rubendibattista/Downloads/Code He-H/build

make
Scanning dependencies of target omega11
[ 50%] Building CXX object CMakeFiles/omega11.dir/main.cpp.o
[100%] Linking CXX executable omega11
[100%] Built target omega11

[rdbisme]

To complement @jbscoggi, @wargnierq can you also post the output of env?

# This command copies the output of `env` in the clipboard on macOS 
env | pbcopy

then paste it here.

[rdbisme]

Ok I had another session with @wargnierq and we finally found the problem.

Normally on macOS cc c++ and gcc are "symlinked" to the local AppleClang and they do not provide GNU suite, in particolar the fortran compiler.

We installed the GNU compiler suite with Macports because @wargnierq needed the gfortran compiler.

Macports provides a system to "enable" a compiler of your choice, such that when you use gcc, the compiler will be the one you specified doing (for example)

sudo port select --set gcc gcc-mp-10

The problem is that doing this, for some reasons, symlinks the command c++ to g++, but NOT cc to gcc.

Now, when you write a CMakeLists.txt like this one:

cmake_policy(SET CMP0048 NEW)
cmake_minimum_required(VERSION 3.0)
project(myProgram)
set(CMAKE_CXX_STANDARD 11)
find_package(mutation++ REQUIRED)
add_executable(yourprogram main.cpp)
target_link_libraries(yourprogram PUBLIC mutation++::mutation++)

CMake starts the scanning for the compilers from the cc command, i.e. in the specific case it detects AppleClang as compiler suite.

If instead you change the project line like this (as it is in the Mutation++'s CMakeLists.txt):

project(myProgram LANGUAGES CXX)

CMake starts the scanning for the compilers from the c++ command, i.e. in the specific case it detects "GNU".

So in facts @jbscoggi was right. Mutation++ was being built by GCC and the client code by AppleClang.

This can be resolved in two ways:

1. Specifying the language for the client program

   cmake_policy(SET CMP0048 NEW)
   cmake_minimum_required(VERSION 3.0)
   project(myProgram LANGUAGES CXX)
   set(CMAKE_CXX_STANDARD 11)
   find_package(mutation++ REQUIRED)
   add_executable(yourprogram main.cpp)
   target_link_libraries(yourprogram PUBLIC mutation++::mutation++)

2. Forcing CMake to detect the right compiler when building Mutationpp

   CXX=/usr/bin/c++ cmake [etc]...

I think this is a bug of Macports in any case not symlinking both C++ and C compilers. I'll try to open a bug upstream.

[rdbisme]

It is indeed: https://trac.macports.org/ticket/48647