XCode Cmake and -fobjc-weak - c++

I have a question regarding a compiling flag -fobjc-weak. Currently, I work on the project that is generated using CMake, it uses C++ mainly and some minimal objective-C code to run the app. When studying compiling flags I saw that some of the Cmake target libraries are compiled with -fobjc-weak and some does not. This is not the flag that I set in CMake so I assume it is automatically added by XCode. My question is why? Where does it come from and what is the reason and implication of this flag being there? I could have missed something but I cannot seem to find out at which stage this flag gets added.
Another piece of information is that I use a iostoolchain.cmake It is identical to this project tool chain. It has a line like this:
#Check if Xcode generator is used, since that will handle these flags automagically
if(USED_CMAKE_GENERATOR MATCHES "Xcode")
message(STATUS "Not setting any manual command-line buildflags, since Xcode is selected as generator.")
I dont really understand how Xcode end up deciding which flags are being added but that is my suspection to why I am seeing this line added when compiling.
https://github.com/leetal/ios-cmake/blob/master/ios.toolchain.cmake
Cheers!

Related

Debugger doesn't locate symbols in source when INTERPROCEDURAL_OPTIMIZATION is enabled

I've been switching a project to CMake and VSCode on my Mac, and encountered a baffling problem: when I enable LTO/IPO, VSCode's C++ debugger doesn't highlight the execution line when breaking. This appears to affect any build target for which I enable IPO.
Here's a minimum example demonstrating the problem:
[main.cpp]
#include <iostream>
int main()
{
std::cout << "This is some text!" << std::endl;
__asm__("int $3"); // Alternatively, use a breakpoint
return 0;
}
[CMakeLists.txt]
cmake_minimum_required(VERSION 3.23.0)
project(TestLTODebugging)
include(CheckIPOSupported)
check_ipo_supported()
add_executable(example main.cpp)
set_target_properties(example PROPERTIES
INTERPROCEDURAL_OPTIMIZATION TRUE
)
I'm using Clang and Ninja, using quick-debugging via VSCode's CMake Tools extension. When run, the app appears to pause as expected, but the line is not highlighted:
And if all I do is turn off IPO/LTO, the issue goes away:
Anyone know where to look for the problem? I'm new to CMake and using VSCode for C++, but this seems super basic and I can't find anything online about this problem. I've had no problems with this when generating an Xcode project with the same source.
While I'm primarily going to be debugging without optimizations, the project I'm working on requires working with optimizations enabled a lot of the time, and I want the debugger to work. I appreciate any help or advice.
EDIT: I've confirmed that this issue does not occur on my PC, where I also tested with Ninja, Clang, and the VSCode debugger. So the problem is either with my Mac environment or is Mac-specific?
EDIT 2: I've now confirmed this affects me with both Ninja and Make files on my Mac. Additionally, both Ninja.build and compile_commands.json (when using Make) show that the only difference between enabling and disabling IPO is the addition of the -flto=thin flag. The -g flag is never removed, and using nm in Terminal shows that the debug symbols are still being generated. I'm now more confident that this is a bug with VS Code or CMake Tools.
I faced a similar problem -- in my case I source annotations for Instruments were missing.
From here:
Note
On Darwin, when using -flto along with -g and compiling and linking in separate steps, you also need to pass -Wl,-object_path_lto,<lto-filename>.o at the linking step to instruct the ld64 linker not to delete the temporary object file generated during Link Time Optimization (this flag is automatically passed to the linker by Clang if compilation and linking are done in a single step). This allows debugging the executable as well as generating the .dSYM bundle using dsymutil(1).
Additional information here.
TL;DR: just add -Wl,-object_path_lto,lto.o to your linker options -- e.g. for CMake: add_link_options(-Wl,-object_path_lto,lto.o).

CMake - get the invoked command line as a var inside CMake

I am looking for a way to get the command invoked to compile a specific file inside CMake as a variable. This is the same "command" as it shows up in a compile_commands.json. It is of the form:
%gcc% %bunch of -DSOMETHINGS% %bunch of -Isome/files% -o %cpp files% ... etc.
The project I am in the process of porting to CMake makes a note of the invoked compiler command inside a file, which I am changing to use the configure_file cmake mechanism. The configured file is needed prior to compiling a specific object.
While searching, I found this answer that is pretty much the same question: cmake - get the used commandline flags "-D". However, it is more than 3 years old, and only concerns retrieving a list of the "-D" flags, which the user solved by manually keeping track. I consider this suboptimal. If this command is written into compile_commands.json, I should be able to access this somehow, right? When exactly is compile_commands.json written? Any change I can get this to write that file for like, a non-functional dummy target or something, then access it and use it to configure my file in the real project?
I know this is kind of against the ethos of CMake, and I love the fact that I don't ever have to manually manage the flags myself, however I find it hard to believe there is no way to get them for a specific file, am I overlooking something?
I have looked at CMake properties on source files, and retrieving them using get_property, however I don't believe I can reconstruct the whole command from these.
I am currently generating Unix makefiles, although the mechanism should optimally also work when generating MSVC project files, which I know CMAKE_EXPORT_COMPILE_COMMANDS does not.
Any thoughts and input on this is greatly appreciated!

codelite clang separate options

I did follow the suggestions on the documentation to enable clang code completion, but it seems that on the most recent version there is no option to add search paths and compiler flags separately, I tried adding compiler flags on the search path window, but is not showing any evidence that it caught the new paths:
Any idea what I'm doing wrong?
You don't need to set the paths separately for clang code completion to work.
You just need to re-build (i.e. clean follow by build) your project once.
If everything is done properly, you should see in CodeLite's build log lines similar to:
codelite-cc g++ ... (or codelite-cc clang++...)
The codelite-cc utility will collect the search paths (and macros and other flags) passed to the compiler and will pass them back to CodeLite, so it will pass it to libClang for getting the proper code completion for your code.

How to compile WindRiver/Eclipse C++ projects from the command line?

I'm currently running a variant of Eclipse known as WindRiver, which is designed for embedded systems programming using C++ (specifically, I'm part of my high school's FIRST Robotics team).
I'm able to successfully compile and build the project from within Eclipse (Project > Build Project) but I'm looking for ways to automate this process by compiling by using the command line.
The project already contains a makefile and everything, so ideally I want to be able to just run that without making any manual changes. I pastebin'd the makefile in case its relevant.
Does anybody know where I can find more information on compiling C++ programs from the command line for either Eclipse or WindRiver or on running makefiles on Windows? I tried looking at "How to run a makefile in Windows?" but following the first answer didn't work (it gave a syntax error for the makefile).
I'm currently using a Windows 8 laptop. As best as I can tell, the current varient of WindRiver I'm using is based on Eclipse version 3.3.1.
You will need a make utility, I believe your WindRiver / Eclipse setup would come with "gnumake" (probably called either make or gmake). You'd nee dto set up the command line path to lead to the compiler and the make executable. Unfortunately, this is not a great answer, as I can't give you exact links to the make and compiler locations (it would of course also depend on where you installed things). I just thought I'd lead you somewhat on the right path, since the question has been up for a little while and no one jumped at it.
Thanks to Mat Petersson's answer, I was able to identify everything I needed and create a batch file that could compile the file for me:
#echo off
setlocal
set PATH=%PATH%;C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\bin;C:\WindRiver\utilities-1.0\x86-win32\bin;C:\WindRiver\setup\x86-win32\bin
set WIND_BASE=C:\WindRiver\vxworks-6.3
cd My_Project\PPC603gnu
make --no-print-directory BUILD_SPEC=PPC603gnu DEBUG_MODE=1 TRACE=1

eclipse and boost unit_test_framework failing syntax check using c++

i have the following Problem.
I started to use the boost library version 1.40, for unit testing.
Since some other people working on the project and not all of them are using eclipse, the program has to be compilable with a makefile. So we used cmake to generate one.
The good thing is, the test is building and working perfectly fine.
But the problem is, when using eclipse (created a c++ makefile project), it complains about several syntax errors (in the sourcecode view).
Something like:
BOOST_AUTO_TEST_CASE( my_test )
{ some code }
will be detected as a syntax error by eclipse. It is really annoying having all these error messages in the IDE. Since after the first line nearly every line in the some code block is marked as having syntax errors as well.
So here is what i tried already:
I added `/usr/include/boost/` to the GNU C++ path options. (properties->C/C++ General->Path and Symbols->Path). This works normally for other external libs that are included by FindPkgConfig in the cmake file. So that the auto completion in eclipse can find the correct classes and function names.
Same way included `/usr/include/boost/test/` directly.
Adding `/usr/lib/libboost_unit_test_framework.so.1.40.0` to the Libraries list.
Adding `/usr/lib` to the Library Paths.
So anyone has a hint how to teach eclipse that the syntax of the boost Macros is correct??
Update:
I forgot:
System is Linux and Eclipse Version is 3.6.1, CDT Version is:
Version: 1.0.0.201009141542
Build id: 201009141542
I don't have a solution but maybe a hint.
I had a similar setup and it worked perfectly until...
the only relevant change I remember is that I changed the name of a test suite.
So (probably) after that, the syntax highlighting went crazy.
I tried indexing and refreshing but it didn't help.
I can't even see the macro expansion because the syntax error prevents it from popping up.
My guess is — still — some indexing issue, because it worked before and I didn't change any include paths. It compiles without problems, but it's urinating these yellow syntax error markers all over the document, which is really, really annoying.
However, it's probably not a path issue because it worked for me before.
I just did this myself using Eclipse Helios, and it does indeed work for me...
Shouldnt you add /usr/include and not /usr/include/boost, since boost is part of the include path used in your program?
For example <boost/unit_test.hpp> is simply <unit_test.hpp> if you include the boost folder aswell..
This is what I have added under GNU c++ include directories:
/usr/local/include //this is where I store the boost folder
/usr/include/c++/4.5.2 //This was needed since not even <map>, <vector> etc would resolve in eclipse.
Intellisense and autocompletion for C++ are pretty much impossible to get right in all cases. If the many macros used in Boost.Test confuse Eclipse, then perhaps you should find a cleaner unit test library. I can recommend Catch, which has a cleaner and friendlier syntax, is header-only so it's much easier to set up, and doesn't rely on macros. It is under active development by another SO user.
I had this problem as well (but on a Mac system). Once I added the boost path to GNU C++ path options, I restarted my operating system and Eclipse doesn't tag BOOST_AUTO_TEST_SUITE as an error any more.