NTNU-IHB / FMI4cpp

FMI 2.0 implementation written in modern C++.
MIT License
93 stars 34 forks source link

boost conan build error with gcc #113

Closed Buckskin closed 2 years ago

Buckskin commented 2 years ago

Hello - I am stuck trying to use fmi4cpp with gcc (gcc version 7.2.0 (x86_64-win32-seh-rev1, Built by MinGW-W64 project)).

I simply cannot get beyond an error related to building the boost dependency. I have tried gcc 7.2.0 and 8.1.0. I have tried boost 1.71.0 and 1.77.0. When I try something like (from the fmi4cpp root folder):

conan install . -s build_type=Release --install-folder=cmake-build-gcc-release --build=missing

I always get:

ERROR: boost/1.71.0: Error in build() method, line 821 self.run(full_command, run_environment=True) ConanException: Error 1 while executing b2.exe -q numa=on target-os=windows architecture=x86 address-model=64 binary-format=pe abi=ms --layout=system --user-config=C:.conan\dc6cdb\1\source_subfolder\tools\build\user-config.jam -sNO_ZLIB=0 -sNO_BZIP2=0 -sNO_LZMA=1 -sNO_ZSTD=1 boost.locale.icu=off --disable-icu boost.locale.iconv=off --disable-iconv threading=multi visibility=hidden link=shared variant=release --with-atomic --with-chrono --with-container --with-context --with-contract --with-coroutine --with-date_time --with-exception --with-fiber --with-filesystem --with-graph --with-iostreams --with-locale --with-log --with-math --with-program_options --with-random --with-regex --with-serialization --with-stacktrace --with-system --with-test --with-thread --with-timer --with-type_erasure --with-wave toolset=gcc define=_GLIBCXX_USE_CXX11_ABI=1 pch=on cxxflags="-fPIC" install --prefix=C:.conan\adfed1\1 -j16 --abbreviate-paths -d0 --debug-configuration --build-dir="C:.conan\7583e0\1"

I hope maybe this is common?

By the way, for Visual Studio 2019, I had other conan boost build issues and ended up skipping conan, installing boost locally, and hand-editing fmi4cpp cmake generated vcproj files. After a lot of work, I got a working library. I started doing the same for gcc but realize this is not the Right Way, so I pause.

Have a great day! -Lance

Buckskin commented 2 years ago

Hi - I should have noted the error occurs during build of the boost wave module.

markaren commented 2 years ago

I would guess this would be an issue for all conan users trying to use gcc on Windows. I don't know much about it.

VS 2019 should build fine as long as you are using x64. The CI builds using both VS2017 and VS2019.

markaren commented 2 years ago

Try specify compiler.libcxx=libstdc++11 perhaps?

Buckskin commented 2 years ago

Thanks a ton for the quick reply!

OK, I will seek help from the boost community for it. My project requires mingw so I hope I can find a solution.

By the way, for Visual Studio 19, I had to manually edit CMakeLists.txt to set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH for most dependent modules before I could get cmake to generate after the conan install (to get rid of errors like missing LIBZIP_LIBRARIES LIBZIP_INCLUDE_DIRS). Then, I had to manually add the include paths and libraries for each dependent modules within the generated Visual Studio IDE projects (e.g. zlib, lzma, bz2, et al). If this is not correct, I can gladly detail my finding in another issue. I also had to comment out "min and max" in one of the templates (typed_scalar_variable.hpp). Then, it worked like a charm :-).

Buckskin commented 2 years ago

Try specify compiler.libcxx=libstdc++11 perhaps? ^^^

Oh yes, I was going to mention I tried both profiles with the same error results:

[settings] os=Windows os_build=Windows arch=x86_64 arch_build=x86_64 compiler=gcc compiler.version=7 compiler.libcxx=libstdc++11 build_type=Release [options] [build_requires] [env]

and

[settings] os=Windows os_build=Windows arch=x86_64 arch_build=x86_64 compiler=gcc compiler.version=7 compiler.libcxx=libstdc++ build_type=Release [options] [build_requires] [env]

Same error for both Release and Debug

markaren commented 2 years ago

By the way, for Visual Studio 19, I had to manually edit CMakeLists.txt to set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH for most dependent modules before I could get cmake to generate after the conan install (to get rid of errors like missing LIBZIP_LIBRARIES LIBZIP_INCLUDE_DIRS). Then, I had to manually add the include paths and libraries for each dependent modules within the generated Visual Studio IDE projects (e.g. zlib, lzma, bz2, et al). If this is not correct, I can gladly detail my finding in another issue.

There might be issues using this library in a VS solution. Never used VS solutions TBH. CMake from the command line and using CLion is known to work. Might be conan related.. Dunno.

I also had to comment out "min and max" in one of the templates (typed_scalar_variable.hpp). Then, it worked like a charm :-).

Ah, yes, the infamous MIN MAX definition on Windows. I should just rename the two getters named min() and max() in this library so that the conflict is resolved without using #define NOMINMAX.

Buckskin commented 2 years ago

Thanks again - I think maybe I am missing a fundamental step (sorry if so). I do not understand what this means in the install.md, and now I wonder if that is my core issue (I don't know what it means to add a dependency to a remote):

Then add a dependency to: fmi4cpp/@ais/stable (stable channel -> releases) fmi4cpp/@ais/testing (development builds -> master) fmi4cpp/version>@ais/testing-<branch (development builds -> branches)>

My steps were:

  1. conan remote add ais https://ais.jfrog.io/artifactory/api/conan/ais-conan-local
  2. conan install . -s build_type=Release --install-folder=cmake-build-release

Did I miss a step to add a dependency to one of the branches (like fmi4cpp/v0.8.0@ais/stable)?

I am able to see:

$ conan search fmi4cpp
Existing package recipes:

fmi4cpp/v0.7.0@FMI4cpp/testing
fmi4cpp/v0.8.0-ALPHA@FMI4cpp/testing
fmi4cpp/0.8.0@FMI4cpp/testing
fmi4cpp/0.8.0@ais/testing

Appreciative!

markaren commented 2 years ago

Ok. So there are two options right.

1) Build fmi4cpp from source.

Assuming windows:

conan install . -s build_type=Release --install-folder=build
cmake . -A x64 -B build -DFMI4CPP_USING_CONAN=TRUE -DFMI4CPP_BUILD_TESTS=ON -DFMI4CPP_BUILD_EXAMPLES=ON
cmake --build build --config Release

2) Add fmi4cpp as a conan dependency to your existing project.

If you look at conanfile.py, you'll see that fmi4cpp requires boost and libzip. These are fetched using conan. Similiarly, in your project you could depend on fmi4cpp. Boost, libzip etc. is then automatically resolved for you by conan. However, as I have not added the conan receipt to some official remote like conan-center, you have to add https://ais.jfrog.io/artifactory/api/conan/ais-conan-local manually. Similarly to how you add custom maven repositories in Java.

In a blank CMake project with no dependencies you could simply create a conanfile.txt with the contents:

[requires]
fmi4cpp/0.8.0@ais/stable

By pointing conan to that file, it would download fmi4cpp and all transitive dependencies. After configuring CMake, you could then link to it using:

find_package(fmi4cpp CONFIG REQUIRED)

target_link_library(target PUBLIC fmi4cpp::fmi4cpp) // I think this is correct

Conan CMAKE_TARGETS might work as well, in which case

target_link_library(target PUBLIC CONAN_PKG::fmi4cpp)

should work...

Conan is worth learning and the procedure is the same for all targets. So you only have to learn it once. I use it consistently on both Linux and Windows. This also ensures that you are working with the same versions across platforms.

Also, I assume Visual Studio has similar integrations with conan as CMake.

markaren commented 2 years ago

In any case, if boost fails to download/build. That's a separate issue, not related to fmi4cpp.

Buckskin commented 2 years ago

In any case, if boost fails to download/build. That's a separate issue, not related to fmi4cpp.

Yes, agree - that make sense to me. This boost issue still remains (for GCC download/build - for VS 2019 it is working). I will need to solve the GCC boost stuff eventually to use fmi4cpp in my project so will keep trying that in parallel and will report back here if I get it working (will seek help outside fmi4cpp for that).

So sorry I realize this issue drifted from GCC to VS 2019. If you request, I will gladly create a different thread for my VS 2019 related questions. After your previous post, I got further with VS 2019 but now I get boost linking issues in the examples. My previous trials somehow now cause CMake to pick up my boost 1.77.0 installation outside the conan data area. Not sure if this is the issue but I will try to scrub boost 1.77.0 from the system to see if it fixes the linker problems.

markaren commented 2 years ago

Here https://github.com/Vico-platform/fmilib-cpp is a C++ wrapper for FMI Library. It does not depend on Boost. It also supports FMI 1.0.

Edit: Sorry. It did depend on Boost, but only for the test suite. So you could modify it. I also see that it links with program_options, which it does not use. So I will update it. I threw it together in a hurry..

Edit2: Removed boost dependency for fmilibcpp

Buckskin commented 2 years ago

Hi - OK, SUCCESS for VS 2019! Thanks so much.

Although my GCC boost issues still remain, I will summarize my understandings for the VS 2019 build and the Install.md related questions here so others may know:

  1. Install.md: Now I understand "add dependency" is meant for the case where you want to add fmi4cpp as a dependency to your project. This was not a second step after "conan remote add ...".

  2. For VS 2019 build, my mistake was thinking the conan install step somehow parameterized cmake using my default conan profile. So after I ran conan install, I still needed to send parameters into cmake for "-A x64 -B build -DFMI4CPP_USING_CONAN=TRUE". Otherwise, the right libraries were not found.

Thanks again. Your support is amazing!

Buckskin commented 2 years ago

Here https://github.com/Vico-platform/fmilib-cpp is a C++ wrapper for FMI Library.

Interesting! I will take a look. This certainly might work better for my project needs. Thanks.

Buckskin commented 2 years ago

Hello – After a lot of work ( :-) ), I was able to get a fmi4cpp library working with GCC tools. However, there are numerous workarounds that cause me to hesitate to build my work on top of it. I surely would like to, so please let me know if you have any insight or otherwise see a better solution.

I capture the solution I have working here, in case others are interested to try it. It uses gcc version 11.2.0 (MinGW-W64 x86_64-ucrt-posix-seh) installed at C:\winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2\mingw64\bin.

The main challenge is there are no released conan GCC configurations for the library and its dependencies.

For the dependent boost and xz_utils libraries, the solutions I found are captured within two issues. For boost: https://github.com/conan-io/conan-center-index/issues/7661. For xx_utils: https://github.com/conan-io/conan-center-index/issues/7665.

The workarounds I found for the fmi4cpp build files:

Here are the build steps I used:

set PATH=C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin;%PATH%
set CC=C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin/gcc.exe
set CXX=C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin/gcc.exe
conan install . -s build_type=Release --install-folder=build --build=missing
cmake . -G "MinGW Makefiles" -DCMAKE_CXX_COMPILER=C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin/gcc.exe -DCMAKE_C_COMPILER=C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin/gcc.exe -B build -DBUILD_SHARED_LIBS=OFF -DFMI4CPP_USING_CONAN=TRUE -DFMI4CPP_BUILD_TESTS=ON -DFMI4CPP_BUILD_EXAMPLES=ON
cmake --build build --config Release

To get the user executable to link, I had to add link libraries for all dependent parts: zip, zlibstatic, lzma, zstd, zlib, and bz2. I had to find the *.a libraries in my conan user data area. I don’t think this step is normal. Is it?

I could not resolve bcrypto dependencies, so had to add stub definitions to (I set breakpoints in my tests and the functions are never called): BCryptDuplicateHash, BCryptHashData, BCryptFinishHash, BCryptDestroyHash, BCryptOpenAlgorithmProvider, BCryptGetProperty, BCryptCreateHash, BCryptCloseAlgorithmProvider, BCryptSetProperty, BCryptGenerateSymmetricKey, BCryptEncrypt, BCryptGenRandom, BCryptDestroyKey.

Here is the working profile for gcc version 11.2.0 (MinGW-W64 x86_64-ucrt-posix-seh) installed at C:\winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2\mingw64\bin:

Conan profile (output of conan profile show default or conan profile show <profile> if custom profile is in use)

[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release
[options]
[conf]
[build_requires]
[env]
PATH=['C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin']
CC=C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin/gcc.exe
CXX=C:/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64ucrt-9.0.0-r2/mingw64/bin/gcc.exe
markaren commented 2 years ago

Remember that Conan is just an option. You can build and link dependencies manually if you prefer.

If I were you, I would have tried https://github.com/modelon-community/fmi-library...

Buckskin commented 2 years ago

Hi - We already use FMI Library and it is certainly OK, but we were looking for a C++ interface. So, I am going to check out your C++ wrapper for it next (the one you mention above).

If you think no one will spend time to take the GCC configuration I provided above further, should we close this issue?

Have a great day. I appreciate your continuous fast responses to my questions!

Buckskin commented 2 years ago

Oh - I should have also mentioned the other reason I am interested in fmi4cpp is we are already using fmi4java in another area of the project so wanted to be consistent.