[CMake] Warning when building static & shared library (DLL) on Windows

[J Decker]

On Sun, Sep 30, 2018 at 3:12 AM Kim Walisch <kim.walisch at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180930/65c74920/attachment.html>