You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So Stacy is working on building one of our projects in Windows that is currently using bump. We ran into an issue that might need to be changed in the FindBump.cmake file. She is trying to build a CMakeList file for our project that uses the FindBump.cmake.
The issue showed up as a linker errors where the compiler was looking for _declspec(dllimport)...blah... symbols. Export.h changes the symbols based on the type of library, and it was wasn't getting set as static and instead jumped to the default. The Bump_LIBRARY_STATIC flag was not getting set anywhere.
The question comes into whether that functionality should be included in FindBump.cmake? Boost has a SET(Boost_USE_STATIC_LIBS ON) method that you are required to set in your CMakeList file to take care of using static libs. Would this be the preferred method of handling this or should the identification of the library type be done by default?
The text was updated successfully, but these errors were encountered:
So Stacy is working on building one of our projects in Windows that is currently using bump. We ran into an issue that might need to be changed in the FindBump.cmake file. She is trying to build a CMakeList file for our project that uses the FindBump.cmake.
The issue showed up as a linker errors where the compiler was looking for _declspec(dllimport)...blah... symbols. Export.h changes the symbols based on the type of library, and it was wasn't getting set as static and instead jumped to the default. The Bump_LIBRARY_STATIC flag was not getting set anywhere.
The question comes into whether that functionality should be included in FindBump.cmake? Boost has a SET(Boost_USE_STATIC_LIBS ON) method that you are required to set in your CMakeList file to take care of using static libs. Would this be the preferred method of handling this or should the identification of the library type be done by default?
The text was updated successfully, but these errors were encountered: