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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Timothy Madden
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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Win cmake belives I am building a .dll, but the only target is an .exe file

Timothy Madden
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 <[hidden email]> 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


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake