I am using bazel to build a c++ application that includes protocol buffers. This means that bazel runs the protocol buffer compiler as part of the build process, and squirrels the generated files away somewhere within the bazel output directory. VSCode is then unable to resolve these #include directives since they are not on any include path that vscode knows about.
But I'd rather not hardcode some frequently-changing bazel output directory in my vscode config. Does anyone have any suggested strategy for resolving this?
You can hardcode <bazel_workspace_path>\bazel-genfiles or <bazel_workspace_path>\bazel-bin as include directories.
bazel-bin and bazel-genfiles are junctions (~= directory symlinks) that point to the corresponding output directories. (They are called convenience symlinks. See the --symlink_prefix flag for more info.)
Related
Intro
I have a CMake-based C++ project. Until now I build and ran the project via CLion. Everything worked fine until I tried to run the .exe-file directly (not via CLion).
Problem
When I navigate to the cmake build directory in order to start my program via the executable file, it fails with the following message in the popup: Cannot continue the code execution because libgcc_s so-1.dll was not found. Reinstalling the program may resolve the issue.
I have the following questions
If I interpret the error message correctly, then this dll is missing on my computer. So I ask myself, why does my program still work when I start it via the development environment (CLion), although the error message expressly states that the source code requires this dll?
Is it the fault of my application/source code that the error appears or rather the current state of my computer? If the former, how can I prevent this error from appearing for other users?
What is the best way to fix this error? It's obvious that I need to download this dll, but where is the best place to put it (which directory and environment variable to use on Window)?
Which source is trustworthy to download this dll? I don't want to download any malware under this dll-name.
Optional: What kind of library is that? What functionalities does it offer?
Additional information
I use CMake as my build tool, CLion as the IDE and MinGW as the compiler.
What I have did so far?
I made sure it still works through the IDE.
I found this dll does not exist in the MinGW installation folder.
I searched the web for more information. Unfortunately, there are only pages unknown to me that only offer the download of this dll. That doesn't satisfy me.
I found the cause of my problem: I had two MingGW installations on my machine. Once the installation that comes with CLion and a separate one. The latter did not have the required dll. However, CLion used its own installation, which in turn owns the DLL. So the solution was to remove the separate installation and include the path to the CLion installation's bin/ directory in the PATH environment variable.
This file is part of MinGW-w64 when using SEH as exception model (as opposed to Dwarf or SJLJ). You need to distribute the .dll files your .exe file(s) depend on in the same folder as the .exe file(s).
If you don't have that file, then you probably have been using libraries compiled with different versions of GCC/MinGW(-w64). I recommend building everything with the same compiler to ensure stable binaries.
Tools like Dependency Walker can help you figure out which .dll files your .exe file depends on.
Or use the command line tool copypedeps -r from https://github.com/brechtsanders/pedeps to copy the .exe files along with it's dependencies.
Analogous setup on *nix:
There is a single project folder with a makefile, and directories for src, build, and target.
In the src directory, I put main.cpp, and other source files (file_0.cpp, file_0.h, file_1.cpp, file_1.h, etc...).
Invoking the makefile (via make, or similar one-line [preferably one-word] script) does nothing fancier than check the src folder if anything is newer than the target, and if so, rebuilds the whole project. (Alternatively, a batch file that just does the compilation regardless of filesystem state would also be "fine"- though I'd prefer a makefile as I could iteratively grow that in complexity as necessary.)
The "build" folder could be used for intermediate build files.
Questions:
What do I need to install? How must I set up my environment? What compilers/tools should I lean into so I'm not fighting the OS? Etc...
My needs for these projects are minimal. The point here is I DON'T want to have to rely on booting up a heavy IDE or similar to putz around with simple C++ projects. Is this achievable in Windows 10?
Problems:
I've tried installing mingw, with msys, and can get cl to produce a .exe, but when I invoke it via a makefile, I get LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'. I've been struggling to find "makefile" resources for windows, as many appear to be straddling different tech stacks (cl vs g++, make vs nmake, etc...)
I'm trying to debug an application compiled with Ninja.
I have my source code /usr/local/...project-src/
I have my build output located at /usr/local/...project-src/out/Debug/build
The compiled output includes debug information
file out/Debug/build includes:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
I'm able to add breakpoints when using relative paths:
cd /usr/local/...project-src
gdb
file out/Debug/build
b x/y.cc:34
# success
Breakpoint 1 at <mem-loc>: file ../../x/y.cc, line 34.
But when I use absolute paths, it fails
cd /usr/local/...project-src
gdb
file out/Debug/build
b /usr/local/...project-src/x/y.cc
# failure
No source file named /usr/local/...project/x/y.cc.
info source prints No current source file.
dir prints Source directories searched: /usr/local/...project-src/out/Debug:$cdir:$cwd
I've also tried:
b ../../x/y.cc, I tried this since that's what the successful command outputs. Surprisingly, it didn't work which is really confusing me.
running gdb from the root directory and other directories.
doing cd to various directories after starting gdb
messing around with set substitute-path and adding directories using dir
I'm hoping the solution is simple, since breakpoints, and variable values, and everything else works, just not with absolute paths.
Also worth noting, once I've successfully added a breakpoint to a file (using the relative path), the other paths also work (both the absolute path and the ../../x/y.cc path).
Lastly, as to why I want absolute paths to work, I'm using CLion's remote-gdb configuration to connect to a gdbserver, and CLion is using absolute paths for whatever reason. Perhaps there is a way to configure CLion to just use the x/y.cc instead? I'm running the gdbserver with gdbserver :2000 out/Debug/build and configured CLion's target remote, symbol file, and sysroot. I've also tried setting the path mappings in CLion.
Edit, testing on a dummy HelloWorld project using g++ -g instead of ninja to build, I'm able to add breakpoints using absolute paths e.g. b /usr/local/...untitled/main.cpp:4. So it seems to be, for some reason, gdb supports full paths for the HelloWorld project built with g++, but not for the real project built with Ninja.
tldr, resolved using gdb --readnow.
Per the comment suggestion I began digging into my build config. 2 things I noticed:
1) The issue disappeared if I built with less debug details. But then I wouldn't be able to inspect expressions & variables. So I thought the issue may somehow related to gdb not having enough memory or cache to load all the debug info. This sounds reasonable since the project source code contains 100,000's of files.
2) As I mentioned earlier, I could add breakpoints using absolute paths after I had added a breakpoint using a relative path to the same file.
I learnt of the info, info set, and info sources commands. Although the outputs were the same between the light-weight debug build and the full debug built (step 1), I noticed that the output of info sources changed in step 2. Before I had added the breakpoint using a relative path, `info sources would list all source files under 'Source files for which symbols will be read in on demand'. But after adding a relative breakpoint, a few of the files (I think the files on the current frame) would be added to the loaded source files.
So I went looking for a way to tell gdb to load all the source files and discovered the gdb --readnow flag (or file <built-file> -readnow with 1 dash -) and though it prints a bunch of warning messages, it seems to resolve my issue.
That being said, I never discovered how to configure CLion to use the readnow flag. The newest EAP (2019.3) release supposedly supports configuring .gdbinit files individual per project, though I haven't tried this. I also don't know if readnow can be configured in a .gdbinit file since it's not a setting. I kind of circumvented the entire configuring CLion issue when I figured how to correctly configure custom build targets and applications in CLion during this investigation.
Edit,
Yet another workaround. If I cd into /usr/local/...project-src/out/Debug which contains the build file (as opposed to /usr/local/...project-src/), then absolute paths work even without readnow.
After importing a c++ Makefile-project into Eclipse, my project depends on some libraries which are located in /usr/include/gazebo-2.2/gazebo.
These are included via the line #include < gazebo/xx/xx.hh>. CMake doesn't have a problem finding the files, Eclipse unfortunately does...
In my include folder, the folder /usr/include/ is set as include path. However it can't find the include files.
Is it possible for eclipse to discover the files without adding the full path to the include directories?
Is it possible for eclipse to discover the files without adding the full path to the include directories?
Since you are using a Makefile project, presumably your makefile specifies the relevant include path. Eclipse can pick this up using its Build Output Parser. The general way to set this up is:
Make sure your makefile can produce output that includes the full compiler command invocations (e.g. gcc -I /usr/include/gazebo-2.2 ... - since this is what the build output parser needs to see), or can be configured to produce that output.
Make sure Eclipse is configured to invoke your makefile correctly (in terms of invocation directory and target name) in Project Properties -> C/C++ Build.
Make sure the build output parser is enabled in Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers tab. If necessary, adjust the "Compiler command pattern" as appropriate.
Perform a build from within Eclipse. Assuming your build is successful (or at least succesful enough for the build output to contain the compiler commands for every source file), the build output parser should then pick up information such as include paths and macros defined on the command line. In the Project Explorer, source files for which settings were picked up in this way will be annotated with a little wrench decoration on the icon.
At this point, your includes should be resolved. You may need to re-build the index to get Eclipse to process the contents of the newly resolved files.
For completeness, since you mentioned CMake, I'll mention that there also exist plugins that will configure a project's include paths directly based on CMakeLists.txt. (I can't recommend a specific one because I don't use CMake myself, but searching for "CMake" in the Eclipse Marketplace should give you several options.)
Is it possible for eclipse to discover the files without adding the full path to the include directories?
No, not unless the include path in question is one of the compiler's default include
paths, which is not so in your case.
If your want the compiler to find the header file referred to by e.g.
<gazebo/xx/xx.hh>
when the required file is:
/usr/include/gazebo-2.2/gazebo/xx/xx.h
then the compiler must be given the include path:
/usr/include/gazebo-2.2
which should appear in compiler commandlines in your build log as:
-I/usr/include/gazebo-2.2
I notice also that your example is actually:
#include < gazebo/xx/xx.hh>
not:
#include <gazebo/xx/xx.hh>
In your example, the leading space will be considered part of the
filename and the header would not be found.
I have a project whose vcxproj file is auto generated prior of compilation by using a script during the build process.
this project dependes on a boost library which is installed in a known location on the build machine.
the project header file declares:
#include "boost/foreach.hpp"
which forces me to manually add the path to the boost root folder to the Additional Include Directories field in the vcxproj file.
As the project file is auto-generated it forces me to split the build process into two stages and edit the project file in between.
i have also tried to change the source file and add the full path in the #include statement:
#include "<path to boost root>/boost/foreach.hpp"
but then some boost internal include fails. Which means i can't proceed in this way.
I have read through Set #include directory from C++ code file to find there is no option to add the path from code.
As I'm now on VS2012/C++11 environment i wonder if anything changed in VS2012 / C++11?
Is it still impossible to add an Include directory using a code statement?
You mean dynamically? No, there is no way. The reason is simple:
When you are running your program, it's already compiled, hence the compiler has to know about all the files to include at compile time.
It seems you're using CMake. If that's the case, I recommend you to add the include dirs in the CMake file.
Firstly, doing this:
#include "<path to boost root>/boost/foreach.hpp"
should be strongly discouraged. By doing that, you're making your source code build-able only on your environment - as your project grows, it will be a nightmare to change the path, or for other developers to build it. And, as you discovered, you'll break any headers which are included further down the chain, which are using relative paths.
What kind of script is generating your project? Is it a custom one, or is it a well known build tool such as SCons or CMake? The correct solution is to fix your build script so that it generates the project with the additional include paths correctly.