[CMake] Win cmake belives I am building a .dll, but the only target is an .exe file

Timothy Madden terminatorul at gmail.com
Fri Nov 24 19:01:49 EST 2017


It turns out this is not a CMake issue.

Sorry for the wrong question. I switched from a makefile to CMake at the
same time I switched from one cpp to 3 cpp in my little project.

The problem occurs when "CL/cl2.hpp" is used in multiple .cpp files, with
or without using CMake to build.

I still don't know why the linker sees multiple definitions, it turns out
it's from a function like this in the header:

namespace detail
{
    static inline cl_int errHandler (cl_int err, const char * errStr = NULL)
    {
        if (err != CL_SUCCESS)
            throw Error(err, errStr);

        return err;
    }
}

(which I understand should be safe to use in a .hpp)

On Thu, Nov 23, 2017 at 2:05 PM, Timothy Madden <terminatorul at gmail.com>
wrote:

> Hello,
>
> In my CMakeLists.txt I have a simple executable target like:
>
> cmake_minimum_required(VERSION 3.2)  # I actually have 3.10 installed
> project(cl-tool CXX)
>
> set(OPENCL_INCLUDE_SEARCH_PATHS ...)
> set(OPENCL_LIBRARY_64_SEARCH_PATHS ...)
>
> if (CYGWIN)
>     set(CMAKE_FIND_LIBRARY_SUFFIXES .lib)
>     set(OCL_LIB_SUFFIX .lib)
> endif()
>
> set(OPENCL_LIBRARY_SEARCH_PATHS ${OPENCL_LIBRARY_64_SEARCH_PATHS})
> set(FIND_LIBRARY_USE_LIB64_PATHS ON)
>
> find_path(OPENCL_INCLUDE_DIRS CL/cl.h PATHS ENV OpencCL_INCPATH
> ${OPENCL_INCLUDE_SEARCH_PATHS})
> find_path(OPENCL2_HPP_INCLUDE_DIRS CL/cl2.hpp PATHS ENV OpencCL_INCPATH
> ${OPENCL_INCLUDE_SEARCH_PATHS})
>
> find_library(OPENCL_LIBRARIES NAMES OpenCL DOC "OpenCL library" PATHS ENV
> OpenCL_LIBPATH ${OPENCL_LIBRARY_SEARCH_PATHS})
> find_package(Threads)
>
> set(CL_INFO_SOURCES cl-matrix-mult.hh cl-matrix-mult.cc
> cl-platform-info.hh cl-platform-info.cc cl-tool.cc)
> *add_executable(cl-tool ${CL_INFO_SOURCES})*
> target_compile_features(cl-tool PRIVATE cxx_std_14)
> target_compile_definitions(cl-tool PRIVATE CL_HPP_TARGET_OPENCL_VERSION=120
> CL_HPP_MINIMUM_OPENCL_VERSION=110 CL_HPP_CL_1_2_DEFAULT_BUILD
> CL_HPP_ENABLE_EXCEPTIONS)
> target_compile_definitions(cl-tool PRIVATE __CL_ENABLE_EXCEPTIONS
> CL_VERSION_1_2)
> target_include_directories(cl-tool PRIVATE ${OPENCL_INCLUDE_DIRS}
> ${OPENCL2_HPP_INCLUDE_DIRS})
> target_compile_options(cl-tool PRIVATE -Wno-ignored-attributes
> -fvisibility=hidden)
> target_link_libraries(cl-tool ${OPENCL_LIBRARIES} Threads::Threads)
>
> But then at build time with:
>
>    cd build && cmake .. -G "MinGW ..." -DCMAKE_CXX_COMPILER=g++
>    gmake VERBOSE=1
>
> I get bellow unexpected behaviour:
>
> CMake is building a static archive with `ar` containing all 3 objects in
> my target executable cl-tool.exe.
> The static archive is then linked in the executable with
> -Wl,--whole-archive. CMake also wants to output an import library,
> Although the target is clearly an executable named cl-tool.exe, on the
> same g++ command line used for linking.
>
> My objects use some templates that are instantiated in 2 of the 3 objects,
> and using --Wl,--whole-archive with these object files,
> results in multiple definitions for the instantiations.
>
> Normally the linker would see the multiple symbols as weak references and
> discard duplicates, but now CMake insists on using
> --whole-archive on the linker command line, so duplicates now result in an
> error.
>
> I have Win10 up-to-date, CMake 3.10, and g++ 7.1, from the MinGW
> installation that comes packaged with Strawberry Perl.
> Also Intel OpenCL SDKincluded and linked with.
>
> This unexpected behaviour is breaking my build, and I am also worried
> about the duplicate / unused code in the resulting executable.
> Is there a proper solution to this problem please ?
>
> Why does CMake go to the trouble of:
>   - creating a separate static archive with the 3 object files (which is
> not requested from the CMakeLists.txt file) ?
>   - using --whole-archive on the resulting .a file instead of linking
> normally ?
>   - attempt to output the import library for an .exe module ?
>
> Apparently CMake believes my target is a .dll (shared library), but
> nowhere in the CMakeLists is a .dll ever created.
>
> I set ENABLE_EXPORTS and CMAKE_WIN32_EXPORT_ENABLE to "OFF", with no
> effect.
>
> --
> Thank you,
> Timothy Madden
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171125/94814205/attachment.html>


More information about the CMake mailing list