VS Code 1.48, Ubundu 18.04, cmake 3.10, gdb 8.1-ubuntu3.2, gcc 7.5.0.
VSC newb, ubuntu newb, unix experienced, cmake experienced, gdb newb, c++ grizzled vet. I'm mostly a windows guy, though I've dabbled with various flavors of Unix since college back in the early 90s. wheeze
I have two project directories loaded into my VSC workspace... both written in C++ with a dash of python hither and yon. The first, we'll call it Orc, works great. All it's tests pass, it's cmake-defined install ran just fine. Life is good.
The second project, we'll call Elf, builds fine, and works fine until it needs to depend on Orc, at which point I get a seg fault. Another call to that same library succeeded (the version check:trivial, no parameters), though I cannot step into that either. When it comes time to tell Orc to do some actual work: boom. I also haven't noticed any core dumps lying about to be interrogated.
(side question: where does VSC stash its core dumps?)
I made sure both projects are debug builds. They're both using the same version of Boost. I've succeeded in running all our unit tests in both Orc and Elf on windows.
What do I need to do to be able to step into Orc so I can see what's going wrong?
I added the following to my CMakeLists.txt and it seems to be happy. There's probably a better way to do it though.
if (UNIX)
add_definition(-ggdb)
endif()
Down side: Always adds -ggdb to Linux builds, including Release... not just the debug variants. Problems in with non-gdb debuggers.
I'm guessing there's a better way to specify a debug-only flag like this, but I'm not sure what that might be. I'm getting familiar with CMake, but I'm no expert.
Related
I have a C++ Xcode project on Mac, and I'd like to see how much code coverage my tests have. If I were building on linux, I would pass a few extra flags to GCC and then use gcov.
What I'm looking for is a way to do something similar on Mac, either through Xcode or through the command line.
This link describes how to get the code coverage tools that Xcode has built in to work, but unfortunately those seem to only work for ObjC or Swift. All the other articles I've found have been similarly unhelpful (either very out of date or only for Swift/ObjC).
I'm not sure how to get this running through the command line, since I'm not even sure what command(s) Xcode uses to build my project (I assume xcodebuild, but I'm not sure what arguments).
I'm fine with doing this either through the command line or through Xcode, whichever is easier.
Any help would be appreciated, please let me know if you need any more details.
Details:
I am using Xcode Version 10.1 (10B61).
I'm building a QT application on Ubuntu that works pretty good. Now I have to deploy it on Windows, so I installed MXE in order to cross compile my sources.
MXE build
git clone https://github.com/mxe/mxe.git
cd mxe
# I need posix threads, that why I build static.posix target
make MXE_TARGETS='i686-w64-mingw32.static.posix' qtbase libxml2
I use a personal library (that uses cmake) and a client/server code for my QT code, that I compiled with MXE and it did not give any error (I worked hard to fix them...). Then, the compilation for the QT reaches the end without any error.
Whenever I try to execute the program (with wine on Ubuntu or on Windows) it does not work. wine freezes and Windows shows me a Runtime Error.
I also tried to use the windeployqt.exe using wine on my executable, hopping it will give me the missing dlls, but it tells me :
Z:\path\release\Executable.exe 32 bit, release executable
Z:\path\release\Executable.exe does not seem to be a Qt executable.
I really have no idea on what is broken. Am I forgetting to put dlls, or is my compilation failing silently ? Does anyone knows or have ideas on how to deal with that case ?
EDIT
Apparently I compile correctly my program, the error seems to come from GetAdapterAdresse when using Windows. The problem is not coming from MXE at all (I'm glad I made it work though).
I'll have to have a look on this function, but anyone knows how to make gdb work with MXE ? When I ran make gdb, it has built something, but I can't figure out where is the program.
I have OSX Yosemite 10.10.5, QtCreator 4.1.0, Qt 5.7.0 and Xcode 7.2.1.
If I write any native C++ program in QtCreator (console, gui - anything) I am unable to debug that program from QtCreator. Breakpoints get ignored, the program executes without pause and runs to completion no matter what I try.
I have tried the Xcode's LLDb, system GDB and Homebrew GDB as debuggers. the versions of GDB fail to start. Homebrew GDB has been codesigned.
This all used to (a few year back) just work beautifully and I am at a loss as to what might have changed.
Curiously, if I generate an exception inside the program - like accessing through a null pointer, the debugger shows me where this happens in just the way I would expect so, presumably, the debugger is running but simply treating me with complete disdain.
I know there are many versions of this question but none seem to address the problem adequately or offer workable solutions, or they apply to much older versions of the products.
Any suggestions?
This version of qtCreator (4.1.0) saw the return of the warning about having the build directory at the same level as the project directory. In Windows, this is done automatically. My mac installation does not get it right. (I may have messed a while back - cannot remember).
So - if the build directory is inside the project directory, debugging fails. Move the build directory up to the same level as the project directory and everything seems to work fine.
You can set the default build directory in the preferences/Build & Run dialogue. The path should start with ../
You will need to think about the folder structure before setting up the project unless you want build folders appearing in awkward places. So, a project folder structure like this is OK:
But one like this is not:
If this was already obvious to you, great. I have been messing with this for ages.
Many thanks to those who replied and anyone else who took the time to read the question. What helped e find it was the suggestion by #AlexanderVX that his setup was the same as mine but his worked. The only bit of my setup he could not see in the screenshots was the start of the build path. So that was the clue.
I'm trying to start a work in vscode , latest C++ plugin version supports ms debugger, so as I'm mostly working under windows it was a signal to try this.
c++ tools plugin from MS and cmake tools were installed.
my test project was however not built . the problem is clear , but I need an advice from experienced vscode users how to solve this right.
cmake doesn't see vc compiler.
(after using QtCreator) I expected that vscode could detect vc installation... however that's not so. ok, I have a two ways:
fill environment variables INCLUDE/LIB/PATH with a headers, libs and binaries
just run vcvarsall.bat x64
Second way is a simple and reliable. so final question is:
how to run .bat at the begining of vscode start?
(I don't mean write another bat/cmd, prepare the environment and run vscode inside the same script after that)
Although the question is fairly old, I'll try to give a useful answer, in case others stumble across, just like I did.
I believe what you are trying to achieve is not possible. Code inherits the environment it was started with. If you did not launch it from a developer command prompt, you will not be able build and debug. (Building might be possible if every task first starts the vcvarsall.bat, but that slows things down by a lot. Debugging I think will still not work.)
If you are willing to, you can check out vector-of-bools CMake Tools extension which does build automation as well as automatic MSVC detection. It builds using CMake (thus you need to write your build scripts using CMake), but it will take care of building just by pressing F7, like what most VS users are familiar with.
I’m porting a C++ sdk from Windows to Mac OSX 10.5. I have a problem in Xcode where my breakpoints in certain files will only be hit if I set them while debugging. If I stop debugging and then restart, the breakpoints no longer get hit. If I add them while not debugging, they don't get hit. This is only in certain files and my breakpoints are always dark blue. i.e. I can’t tell the difference between a breakpoint that will get hit and one that won’t.
Specifically, my sdk is made up of various dynamic libraries. These are built using Perforce jam, which calls the various compile and link executables depending on my OS and compiler version (such as Visual Studio’s cl.exe and link.exe). I have a simple (unit testing) command line application that links to these dynamic libraries and calls code in them. This application on Windows is a Visual Studio project, in which I set breakpoints on library code and expect them to be hit.
I’ve created the same C++ command line utility application in Xcode 3.1.2 that links to the sdk dylibs and calls code in them. Some of the breakpoints work fine. I can set breakpoints in code that’s called from the troublesome code, and step out to the troublesome code, which I can then step through fine. The troublesome code is compiled into the same dylib as code that works fine. It’s also long and complicated enough not to be a candidate for inlining.
I’ve tried the following:
Turn Load symbols lazily off.
Compile with both gcc 4.0 and gcc 4.2.
Do a full clean and shutdown.
Delete the user-specific files of the xcodeproj package.
Rename the files so they can’t clash with system files.
Clear everything out of the Breakpoints window.
Create a new Xcode project.
My application is compiled in debug with DWARF format and my libraries are built with the –g flag (along with –v, –arch i386 and –fvisibility-inlines-hidden).
Help would be much appreciated. Thanks.
Update: sorry for not updating this, my Mac port project was postponed. I never resolved this, but discovered that it actually only occurs in constructor bodies. I'll revisit this as and when I hit the problem again.
Have you tried these?
Why aren't my breakpoints working?
Not really an answer: You should make a bug report in the official Apple bugtracker. The chances are high that you get an answer sooner or later there - or perhaps it is really a bug.