Thanks!
On Sun, Sep 30, 2018 at 12:41 PM J Decker <d3c...@gmail.com> wrote:
>
>
> On Sun, Sep 30, 2018 at 3:12 AM Kim Walisch <kim.wali...@gmail.com> wrote:
>
>> Hi,
>>
>> I have recently found out about CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS which
>> allows
>> to easily build a shared library i.e. DLL on Windows. It works great and
>> it is an awesome
>> feature however I have run into a warning on Windows (using cmake, ninja,
>> MSVC) because
>> my CMakeLists.txt builds both a static and shared library.
>>
>> Here is what my CMakeLists.txt does:
>>
>> if(WIN32)
>> set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
>> endif()
>>
>> add_library(mylib SHARED ${LIB_SRC})
>>
> make this 'mylib-sh'
>
>> ...
>> add_library(mylib STATIC ${LIB_SRC})
>>
> make this 'mylib-st'
>
>> ...
>>
>> This works without any issues on all Unix-like OSes. However on Windows
>> with MSVC I found
>> out that building the shared library creates both mylib.dll and
>> mylib.lib. And building the static
>> library also creates mylib.lib which causes ninja to issue the following
>> warning:
>>
>> ninja: warning: multiple rules generate mylib.lib. builds involving this
>> target will not be correct; continuing anyway [-w dupbuild=warn]
>>
>> So my question is how to best deal with this warning:
>>
>> 1) Should I ignore it?
>>
> you need the .lib to later link to the .dll so no...
>
>>
>> 2) Should I use add_library(... MODULE ...) instead of SHARED on Windows?
>> The ninja
>> maintainer's have suggested this when another user reported the issue
>> here:
>> https://github.com/ninja-build/ninja/issues/1128#issuecomment-207058115
>>
>> One issue I see with this approach is that apparently when building a
>> shared library using
>> add_library(... MODULE ...) one should avoid
>> using target_link_libraries(binary mylib)
>> as mentioned in this stackoverflow answer:
>> https://stackoverflow.com/a/4968940/363778
>> However the author of the stackoverflow answer also mentions that on
>> Windows you
>> could probably still use target_link_libraries(binary mylib)!?
>>
>> 3) Or is there another known workaround for this issue.
>>
> Could just use unique names.
> There's little use in practice in linking against both... if you really
> want to do both and have it be either
> just use add_library and let the user of the library deside if static or
> shared should be enabled.
>
>>
>> Thanks,
>> Kim
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
--
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:
https://cmake.org/mailman/listinfo/cmake
