Hi,
I'm facing the following cmake error while compiling RTI Perftest v3.2.0 with DDS Micro v3.0.3 on Windows. The cmake version is 3.20.5.
Command: build.bat --platform x64Win64VS2017 --micro
Output:
[INFO]: Compilation flag for msbuild is: release
[INFO]: Generating types and makefiles for C++
INFO com.rti.ndds.nddsgen.Main Running rtiddsgen version 3.0.1.7, please wait ...
INFO com.rti.ndds.nddsgen.Main Done
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
[INFO]: Compiling C++
[INFO]: Using NMake for the CMake generator, use --cmake-generator to specify other.
CMake Error: Unknown argument --target
CMake Error: Run 'cmake --help' for all supported options.
[ERROR]: Failure compiling code for C++.
Have you set the required environment variables?
Please see Section 3.2.1
https://community.rti.com/static/documentation/perftest/current/compilation.html
specifically,
The
%NDDSHOME%
environment variable should be set correctly. Alternatively,%NDDSHOME%
can be passed directly to thebuild.bat
script by using the--nddshome <PATH>
command-line option.When compiling for RTI Connext DDS Micro, the
%RTIMEHOME%
environment variable should be set correctly. Alternatively,%RTIMEHOME%
can be passed directly to thebuild.bat
script by using the--rtimehome <PATH>
command-line option.Hello Howard,
Yes, I'm following the compilation steps mentioned in the document and also settting this environment variable.
Could this be a cmake version comptibility issue? I see only 1 statement in the build script which has --target and if I remove that, the script proceeds but later fails with the following error:
rti_me_cppz.lib(DomainParticipantFactory.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86'
I had compiled DDS Micro for x64 and wanted to build RTI Perftest for the same. I tried to ensure 'win_arch' and 'cs_win_arch' are x64 in the script but I still have the same error.
Hello,
I think you removed the wrong option, lets check this out:
The problem seems to come from the following part of the build script:
There, is where we pass the "target" to cmake. It is weird that it is not finding it in your case, but I think you can potentially just remove
And still being able to build. Can you check this out? Make sure you do a "git clean -xdf" prior to rebuild (to clean all the cmake cache files).
Oh, btw, make sure to remove in both calls to CMAKE, in the generation and in the build steps.
Hello Javier,
I had removed '--target perftest_publisher' from the generation part earlier (but now also in the build step) and it had removed the earlier cmake error.
But now I'm stuck at the error I descibed in my last comment:
How do I change the target machine type to x64 when compiling Perftest for DDS Micro? Is there an option which I'm missing? (Note that I was able to compile and run C/C++ examples from Visual Studio by creating new x64 platform with settings copied from Win32.)
Hi, sorry, I thought you deleted something else, hence asking you to repeat the same steps, my apologies.
This error is indeed extrange, but I have some hints: I believe the problem might be due to nmake being an x86 application (given the path), maybe it is not able to compile x64 stuff. We could potentially try the following:
- CMake has the option to generate the output as a Visual Studio Solution (we don't use such option because it is quite dependent on the VS and CMake installed, that is why we default always to NMake). You can check which options you have for the generators by doing: "cmake -h" and check the "Generators" section. You will probably have specific ones for Visual Studio, choose one (and make sure to add the x64, so it does not generate the code for x32, those are listed by pairs if I recall correctly).
- Either use the command line option in the build.bat to pass the name of the compiler or just override the CMAKE_GENERATOR variable it in the build script, here, in the -G !CMAKE_GENERATOR!
Optionally, after that same call add a stop for the script to continue doing everything manually:
And open the Visual Studio Solution (from a terminal where your RTIMEHOME variable is set) and compile it graphically with Visual Studio or with MSbuild.
Let me know how it goes with this method.
Hi, I had tried changing the CMAKE GENERATOR to "Visual Studio 16 2019". I see the same error regarding "--target", so when I try after removing '--target perftest_publisher', I see the following output (attached) with a lot of linker errors.
I also see one message regarding vcpkg:
Ok... so now you are generating the solution, did you add the exit call I mentioned to you? Then do you open the .sln from the terminal with Visual Studio or what do you do?
> Graphically I believe there should be on the top part a section where it allows you to select debug or release, isn't that selected, it should be "Release".
> If you are using CMake to build, I think you need to add
Hi Javier,
Thanks. I added the exit call after the cmake generation step (and removed the '--target perftest_publisher' from that line). Then I opened the .sln and built the solution from Visual Studio.
When I build for Debug mode, it completes successfully (and I'm able to run perftest pub-sub), but when I change to Release mode. I see similar errors which I saw when I was building using cmake (see attached). Could you throw some light on why this should be happening?
Good! At least we see some progress there.
I was wondering if you built the Micro libraries both for release and debug. Could it be possible that you only built Micro for debug and not release? I would expect to see different errors there, but it is true that I have not dealt with these issues before.
Alternatively, I googled the linker error a bit and I got a couple of hits, not sure if any of them will fit your use-case, but it might be worth trying. Disclaimer: usually building Perftest for Micro on Windows is painless. I am not sure why your configuration is giving us so much trouble!
These were the 2 things I found for:
Ans1> The problem comes from /NOENTRY option in Project Properties->Linker->Advanced->No Entry Point. Removing it solved the problem
Ans2> It seems like my problem was that I was using the /NODEFAULTLIB argument, and removing that made the errors go away.
Hi. Both the solutions in Ans1 and Ans2 were already in place.
I compared the profile of Debug and Release in perftest_publisher.vcxproj and everything looks correct.
I had only built Micro for Release and was linking the same for both Debug and Release modes in Perftest. (I had also built debug libraries for Micro separately which all have a 'd' suffix but I'm not using them, nor are they in any PATH).
Hmmm...
Could you check what are the flags that change between release and debug in the solution? It must be one of these, since the target libraries will be the same in both cases and with debug you are able to compile.
Hi, I found the issue behind linker errors in Release mode.
Actually the solution files generated had the following setting in both Debug and Release configurations:
The runtime library options used are (C/C++ -> Code Generation -> Runtime Library):
Since only msvcrt.lib was ignored in both configurations, it did not affect Debug mode (since it could link againt the default msvcrtd.lib).
@Javier, you had mentioned regarding removing /NODEFAULTLIB option which I had also checked, and this is actually related to that where only a specific default library was ignored.
Thanks for all the help :)
Glad to know you resolved this!
In any case, I discussed your issue with our Micro team and they mentioned they were able to reproduce this issue, but it got solved by using the Visual Studio Command line prompt (the one for Native x64 builds), with no need to performn changes in the build script. It might be worth giving it a try if you were not using it already.
Regards,
Javi
I had been using the VS Developer Command prompt all this while. I just tried the 'x64 Native Tools Command Prompt for VS', and I was able to build for Micro from command line (although I still had to remove '--target perftest_publisher' as it was throwing the cmake error, but no change of generator was needed).