ninja does not support cmake build of both shared and static libs on windows when using cmake's OUTPUT_NAME

[MarkMLunarG]

In windows this cmake language can be used to build both static and dyn libs:

add_library(MyLib SHARED source1.c source2.c)
add_library(MyLibStatic STATIC source1.c source2.c)
set_target_properties(MyLibStatic PROPERTIES OUTPUT_NAME MyLib)
target_link_libraries(MyLib)

But only MyLib.dll is built by ninja, no MyLib.lib is built. When the ninja build is run, this warning is generated:
ninja: warning: multiple rules generate MyLib.lib. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]

All attempts to link against MyLib.lib then fail

[jimon]

Maybe it's a problem with cmake and not ninja than? How does cmake behave when generating makefile in this case?

[MarkMLunarG]

It works as expected with visual studio and the build rules with ninja look
right, though I may be missing something subtle. Perhaps this weekend I can
look at the Ninja code that is triggering the message and some other things
to see what that reveals.

On Thu, Apr 7, 2016 at 1:04 AM, Dmytro Ivanov notifications@github.com
wrote:

Maybe it's a problem with cmake and not ninja than? How does cmake behave
when generating makefile in this case?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1128 (comment)

[evmar]

I don't know much about cmake, but:

• the snippet you posted indicates it renames something (with the
  OUTPUT_NAME thing)
• you're saying it isn't creating some filename you expect
• ninja is complaining about multiple rules generating something

From these I conclude:

• by default, cmake rules generate some files file1 and file2
• your settings make cmake write two rules that both want to produce file1

On Wed, Apr 6, 2016 at 8:30 PM, MarkMLunarG notifications@github.com
wrote:

In windows this cmake language can be used to build both static and dyn
libs:

add_library(MyLib SHARED source1.c source2.c)
add_library(MyLibStatic STATIC source1.c source2.c)
set_target_properties(MyLibStatic PROPERTIES OUTPUT_NAME MyLib)
target_link_libraries(MyLib)

But only MyLib.dll is built by ninja, no MyLib.lib is built. When the
ninja build is run, this warning is generated:
ninja: warning: multiple rules generate MyLib.lib. builds involving this
target will not be correct; continuing anyway [-w dupbuild=warn]

All attempts to link against MyLib.lib then fail

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1128

[ngladitz]

Both the SHARED library and the STATIC library will produce a file called MyLib.lib.

For the former it's the DLL's import library for the later it's the static library itself.

Even if visual studio doesn't diagnose this it likely results in one silently replacing the other which probably isn't what you want either.

[MarkMLunarG]

That is not what I observe. Ninja is producing only the MyLib.dll
successfully, Visual Studio produces both successfully. Additionally, the
TARGET_FILE = rule for both versions in the build.ninja files are correct:
the shared link rule has a MyLib.dll TARGET_FILE and the static link rule
has a MyLib.lib target file.

I tried hacking the build.ninja file and found I could make the warning go
away by changing the statement in the build.ninfa file from "build
layers\MyLib.lib: CXX_STATIC_LIBRARY_LINKER__" to "build MyLib_static.lib:
CXX_STATIC_LIBRARY_LINKER__" OR to "build MyLib.xxx:
CXX_STATIC_LIBRARY_LINKER__". Changing other things had no impact on the
problem.

So my guess is that there is a lexical compare that considers MyLib.lib and
MyLib.dll to be equal but MyLib.dll and MyLib.xxx are not. The code in
question appears to be around line 348 of manifest_parser.cc.

On Thu, Apr 7, 2016 at 12:28 PM, Nils Gladitz notifications@github.com
wrote:

Both the SHARED library and the STATIC library will produce a file called
MyLib.lib.

For the former it's the DLL's import library for the later it's the static
library itself.

Even if visual studio doesn't diagnose this it likely results in one
silently replacing the other which probably isn't what you want either.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1128 (comment)

[ngladitz]

I am not sure what you mean by "both"?

• The SHARED and STATIC library targets
• or the DLL and its import library (both of which belong to the SHARED library target)

If you don't have / want an import library for your DLL (e.g. because you are creating a runtime loadable plugin without DLL exports rather than a linkable library) you should use the MODULE rather than SHARED library type.

Either way you can not have two files occupy the same space at the same time.

[MarkMLunarG]

Ah, forehead slap, I see it now. This is not the first bug that Ninja has
uncovered in this build that VS is clueless about. Thanks!

On Thu, Apr 7, 2016 at 1:28 PM, Nils Gladitz notifications@github.com
wrote:

I am not sure what you mean by "both"?

• The SHARED and STATIC library targets
• or the DLL and its import library (both of which belong to the
  SHARED library target)

If you don't have / want an import library for your DLL (e.g. because you
are creating a runtime loadable plugin without DLL exports rather than a
linkable library) you should use the MODULE rather than SHARED library type.

Either way you can not have two files occupy the same space at the same
time.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1128 (comment)