I have a cmake project that is part of some larger environment.
There are some cmake makros/functions that I have to use to set up my project.
At some point they add a compile flag:
TARGET_COMPILE_OPTIONS (${name} PUBLIC "$<$<CONFIG:Release>:/GL>")
however, i want to remove this flag afterwards because it causes some inconvenience in my project.
But there seems to be a bug in cmake:
I tried to to remove the flags from the INTERFACE_COMPILE_OPTIONS and COMPILE_OPTIONS (this is there target_compile_options adds the options according to cmake doku ).
message commands before and after the removal shows the success but the generated vcxproj file still contains the
<WholeProgramOptimization>true</WholeProgramOptimization>
in the <ItemDefinitionGroup><ClCompile> section.
So it seems that adding the /GL flags triggers some internal state change that can not be removed afterwards. (if i remove the addition of that flag in the macro I have to call, then the WholeProgramOptimization node is not added to the vcxproj)
Did I miss something?
I can just add a /GL- as an option but then I get a lot of D9025 warnings (override /GL with /GL-)
(tested with cmake 3.15 and 3.13)
It turns out, that the problem is that the cmake scripts I have to use sets the optimizer settings with PUBLIC as scope
TARGET_COMPILE_OPTIONS (${name} PUBLIC "$<$<CONFIG:Release>:/GL>")`
^^^^^^
Another dependency of my project uses the same function and gets this flag into its INTERFACE_COMPILE_OPTIONS and my project inherits this option without possibility to remove it.
The only way seems to be to get the common scripts fixed to use PRIVATE scope instead. This would be more logical, since its an internal target property that does not have any implications to the consumer.
Related
Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.
The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.
I have a project that is running fine on Android and WinPhone 8. When I attempt to run on iOS, I've getting the following error
Microsoft.Practices.ServiceLocation.ActivationException: Cannot
register: No public constructor found in x
where x is whatever SimpleIoc.Default.Register<T, TU>(); the flow hits first. I've moved the code around (as suggested elsewhere) to ensure all of the platform specific SimpleIoc calls are made in ViewModelLocator.
I've added public default ctors in the classes that are complaining about the error (I have though set the PreferredConstructor to the original, not the newly added public ctor).
I have a feeling that this error is a false positive (something else is failing, but pointing at that code).
Using Xam.iOS via a build server (the code is coming from VS2015). Xcode is running the 8.3 emulators (it may need updating to allow for 8.4 testing)
It could be that the Linker is optimising away the constructor, if it thinks it's not used. Try setting the Linker Options to "Don't Link" and see if it does it again, or even new-up an instance of the class elsewhere so that the Linker knows that the constructor is used. You don't necessarily want to leave it that way, but if it eliminates the error, you'll at least know the reason.
The [Preserve] attribute did the trick for me.
Decorate constructor with it and keep your linker settings.
This attribute is part of the Microsoft.WindowsAzure.MobileServices namespace.
I have the following projects in a Visual Studio 2012 solution:
Native (no /clr) static lib project, compiled with /ZI for Edit And Continue.
C++/CLI DLL project, which references the above static lib.
The C++/CLI project builds with the following warning:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification
If /OPT:NOLBR is added to the linker options of the C++/CLI project, the warning becomes:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
Any attempt to change the incremental linkage setting of the C++/CLI project doesn't change the warning (C++/CLI projects never link incrementally anyway).
I understand that I won't be able to use Edit And Continue in the C++/CLI project, because this is not supported. Indeed, changing /ZI to /Zi (disabling Edit And Continue) in the static lib project eliminates the warning, but I can't do that - other non-CLR consumers of that lib need to use Edit And Continue.
How can I get rid of this warning without disabling Edit And Continue in the static lib (and hopefully without maintaining separate build configuration for native and CLR users of the static lib)? I mean, is there any way to ask the linker to ignore the /EDITANDCONTINUE directive that is embedded in the referenced static lib (much in the same way that /NODEFAULTLIB can ignore /DEFAULTLIB directives)?
I have created a minimal VS solution that reproduces the described issue.
due to '/OPT:LBR' specification
This is a nonsense error message, that linker option is only effective for ARM binaries. This is simply a bug, using /OPT:NOLBR takes the sting out of it and you get the real warning.
Which is accurate enough, although it doesn't win any prizes either, you asked for Edit+Continue support in your static lib project but that is not available for a mixed-mode .NET assembly. The undocumented /IGNORE linker option is available to suppress warning messages but this one is ranked as an "unignorable warning" by Chapell.
You'll have to live with this warning as long as you don't want to change your static lib project. It is completely benign. You won't get it when you recompile it with /Zi.
There is no other way than to
disable "Edit And Continue" in the library
create a separate build configuration for "Edit And Continue (/ZI)" and "Program Database (/Zi)"
Of course: I am not aware that there is a predefined macro to determine between /ZI and /Zi... so you need to define your own preprocessor directive to distinguish between these configurations...
I had the same problem and found the only solution is to delete the .vcxproj and .sln files of the project and create the project again.
But then in an old copy of the same project I found a better solution: I changed in the projectname.vcxproj file the line
Profile true
to
Profile false
and LNK4075 warnings disappeared.
It had been the Visual Studio Profiler who had caused the troubles.
How do I add linker-flags "DEF" and "NODEFAULTLIB" to vs2012 project via CMAKE?
You can append them to CMAKE_EXE_LINKER_FLAGS:
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def /NODEFAULTLIB")
endif()
The general way is to add linker flags to CMAKE_xxx_LINKER_FLAGS, yes. However in case of CMAKE_SHARED_LINKER_FLAGS and /DEF: parameter, there is a special case that made me run into trouble.
If you already use CMAKE_EXPORT_ALL_SYMBOLS (CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS) then the /DEF: parameter will not appear in the linking command, even if you specified it in CMAKE_SHARED_LINKER_FLAGS.
This is because MSVC linker accepts only one /DEF: parameter, and CMake does not want to override the existing one: /DEF:<build_path>/exports.def (which is added due to CMAKE_EXPORT_ALL_SYMBOLS) with the one which you specify in the CMAKE_SHARED_LINKER_FLAGS.
You can use also CMAKE_CXX_STANDARD_LIBRARIES. It adds arbitrary linker flags without checking them, but it adds them into the middle of the linking command before the /DEF:<build_path>/exports.def so that the latter won't get overridden.
The full discussion of this case here: https://cmake.org/pipermail/cmake-developers/2019-November/031274.html.
How do I link ".a" fat-static-libs with Apportable?
In the beginning, I did get a warning,
Warning: Library not found for lib-name. Try adding this to the
'deps' array in the 'add_params' section of your configuration.json
file. Check ~/.apportable/SDK/System for the directory names that
correspond to 'deps' entries.
I did add it to "deps" in the JSON right where it says this:
// A list of dependencies. Typically these correspond to frameworks in the xcode project.
My library isn't a framework, though. It's just a .a static library that has armv7, armv7s, and i386 parts which I assembled using lipo from two libraries (an armv7 and armv7s .a and a i386 .a) built with Xcode. They both use a single framework which is this Boost framework.
Adding it under deps squelched that warning message, but the apportable linker is still giving undefined references, so it is still not properly linking this file.
Now I know that Apportable has to re-jitter all this stuff, since Android won't know what to do with a Mac-executable format, so it's probably got to go pick apart my library and possibly turn it into an ELF-library before final linking. I'm not sure how to go about debugging this at this point, but is this supported at all?
Since you get "library not found" that means Apportable simply can't find the file. Hence the problem is merely with the file's location (or existence) and not what's in the library or how it is built.
The most common issue with dependent targets, especially Xcode projects dropped into other Xcode projects respectively workspaces with multiple projects, is that the resulting output of each target/project goes to different folders. Then Apportable (as well as xcodebuild under some circumstances) can't find the resulting libraries.
First step you should try is to make sure that the target dependencies are set. Select the app target, go to the Build Phases pane and under Target Dependencies add all frameworks and libraries that appear in the list and that your project depends on. This should ensure that the dependent frameworks/libraries do get built - because Xcode's built-in automatic dependency resolution isn't available to command line tools from what I understand. So you need to explicitly specify the dependent projects respectively their output.
If that doesn't help, you can force all targets to write their output to the same folder. Under Build Settings for every target change the Build Products Path (symbolic name: SYMROOT) to the same folder, for example ~/myprojectsbuildoutput
That way even dependent other projects will place their output in the same folder and xcodebuild as well as Apportable (it depends on xcodebuild) will be able to find the library files.
Tip: make sure your project builds successfully on the command line. Open Terminal, cd into the folder where the .xcodeproj bundle is and enter xcodebuild. If xcodebuild fails merely due to validation, disable Validate Built Product under Build Settings of the app target. If xcodebuild fails, Apportable likely isn't going to work either because it depends on xcodebuild. So as a prerequisite make sure that xcodebuild works on your project.
If xcodebuild also gives you "library not found" try calling it with a specific SYMROOT:
xcodebuild SYMROOT=~/myprojectsbuildoutput
If that then works you know you have to update each target's Build Projects Path. From what I know it's not currently possible (or not documented) to pass custom xcodebuild parameters via Apportable, so it needs to be set up in the .xcodeproj itself.