Build Problems when Upgrading from v3.5.9 to v3.6.0

[CleanHit]

In my CMakeList.txt I import SEAL v3.5.9 using:

include(FetchContent)
############################################################################################
# Get the SEAL Package
############################################################################################
message(CHECK_START "Fetching SEAL")
set(SEAL "seal")
FetchContent_Declare(
        ${SEAL}
        GIT_REPOSITORY  https://github.com/microsoft/SEAL
        GIT_TAG         v3.5.9
)

FetchContent_GetProperties(${SEAL})
if(NOT ${SEAL}_POPULATED)
    FetchContent_Populate(${SEAL})

    # Build shared libraries
    # Store the old value of the 'BUILD_SHARED_LIBS'
    set(BUILD_SHARED_LIBS_OLD ${BUILD_SHARED_LIBS})
    # Make subproject to use 'BUILD_SHARED_LIBS=ON' setting.
    set(BUILD_SHARED_LIBS ON CACHE INTERNAL "Build SHARED libraries")
    message("Build SEAL shared lib is set to: ${BUILD_SHARED_LIBS}")
    add_subdirectory(${${SEAL}_SOURCE_DIR} ${${SEAL}_BINARY_DIR})
    if(${BUILD_SHARED_LIBS} STREQUAL "ON")
        set(SEAL_SHARED "seal_shared")
    endif()
    # Restore the old value of the parameter
    set(BUILD_SHARED_LIBS ${BUILD_SHARED_LIBS_OLD} CACHE BOOL "Type of libraries to build" FORCE)
endif()

It is being downloaded into <my_project_path>/cmake-build-debug/_deps/ with the sub folders seal-build, seal-src and seal-subbuild. I can bind it to my project using:

target_link_libraries(my-projrct PRIVATE
        ${SEAL}
)

After that SEAL is being built in seal-src on the first run and I can just import the library with #include <seal/seal.h> in my project. The problems start when I get v3.6.0, for some reason:

1. #include <seal/seal.h> isn't being found anymore.
2. It messes with my other project dependencies, they get downloaded and built under <my_project_path>/cmake-build-debug/_deps/seal-src/thirdparty/ instead of under <my_project_path>/cmake-build-debug/_deps/ as with v3.5.9.

I guess this behavior has something to do with the changes made to SEALs CMakeLists.txt file in v3.6.0, but I can't figure out what is causing this behavior that brakes my project.

[CleanHit]

I use Fedora 33 OS and CLion for C++ development. Here is a minimal example project with a CMakeList.txt file to demonstrate the problem. Just build with the defined v3.5.9 and then rebuild it with v3.6.0.

problem-child.tar.gz

[kimlaine]

Thanks for reporting this! The causes of your issues 1. and 2. are totally independent.

1. There is a mistake in your CMakeLists.txt. When calling target_link_libraries, the SEAL target you use is seal, when it should be seal_shared (you are building the shared library). There is a difference in behavior between SEAL 3.5 and 3.6 that makes it so that it worked before: SEAL 3.5 always builds the static library, whereas SEAL 3.6 only builds either the static or the shared library depending on the BUILD_SHARED_LIBS option. The problem becomes more confusing because if target_link_libraries can't find a CMake target by that name, it automatically searches for library filenames directly, what happens is that it will try to find a file called libseal.a or libseal.so, but even if such a file is found that obviously doesn't bring in the appropriate include directories. I highly recommend using SEAL::seal or SEAL::seal_shared as the target when calling target_link_libraries so you will get a warning if they are not found for whatever reason. This didn't work in SEAL 3.5 because these ALIAS targets were not created there, but it works in 3.6.

2. There was a bug in our CMake system that overwrote FETCHCONTENT_BASE_DIR, which caused the strange behavior that you saw. We just released a hotfix (no version number change). Clear your build directory, fix the problem 1. above, try again, and let us know if there is still an issue.

Thanks again for the detailed bug report!

[CleanHit]

Thanks for pointing out the difference between seal and seal_shared libs in v3.6.0 and the second issue is completely gone. When I try with v3.6.0 and use SEAL::seal_shared I'm getting the error zstd.h: file or folder was not found with the suggestion to use #include "zstd.h", everything works fine when I build the static one and use SEAL::seal.

I've noticed some differences between v3.5.9. and v3.6.0 regarding built libraries:

1. v3.5.9: creates its lib files under <my_project_path>/cmake-build-debug/_deps/seal-src/lib/. Both the static (default) and the shared (on demand) libraries are being created.
2. v3.6.0: creates its lib files under <my_project_path>/cmake-build-debug/_deps/seal-build/lib/. The static library is being created when BUILD_SHARED_LIBS=OFF, but fails to create the shared one when BUILD_SHARED_LIBS=ON.

[kimlaine]

Just pushed out a new hotfix to address the issue with zstd.h. It should work now. Please let us know if there are further issues and we'll try to address them as quickly as possible.

[CleanHit]

All the build related problems are gone.