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

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

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

Kim Walisch
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})
...
add_library(mylib STATIC ${LIB_SRC})
...

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?

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:

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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Warning when building static & shared library (DLL) on Windows

J Decker


On Sun, Sep 30, 2018 at 3:12 AM Kim Walisch <[hidden email]> 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:

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
Reply | Threaded
Open this post in threaded view
|

Re: Warning when building static & shared library (DLL) on Windows

Kim Walisch
Thanks! 

On Sun, Sep 30, 2018 at 12:41 PM J Decker <[hidden email]> wrote:


On Sun, Sep 30, 2018 at 3:12 AM Kim Walisch <[hidden email]> 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:

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