I want to debug an executable generated with Bazel. The gdb debugger is lost with the links generated by Bazel and is not able to show me the C++ source code. How to fix that?
The project root directory is /home/.../Cpp/
./Cpp/
├── bazel-bin -> /home/picaud/.cache/bazel/_bazel_picaud...
├── bazel-Cpp -> /home/picaud/.cache/bazel/_bazel_picaud...
├── bazel-genfiles -> /home/picaud/.cache/bazel/_bazel_picaud...
├── bazel-out -> /home/picaud/.cache/bazel/_bazel_picaud...
├── bin
│ ├── BUILD
│ └── main.cpp
├── MyLib
│ ├── BUILD
│ ├── ....hpp
│ ├── ...cpp
└── WORKSPACE
The first step is to generate executables using the debug mode:
bazel build ... --compilation_mode=dbg -s
(the -s option is not mandatory it only shows the executed commands, you can remove it if you want)
gdb debugging from the command line:
You can start gdb with this command (from your project root directory):
gdbtui bazel-bin/bin/main
-> everything is okay, you should see your C++ source code.
The error would be to do:
cd bazel-bin/bin/
gdbtui main
In that case, because of the links, gdb is not able to retrieve the source code.
gdb debugging from Emacs:
Do as usual
M-x gdb
In the emacs prompt define the complete absolute path to the executable:
gdb -i=mi /home/picaud/.../Cpp/bazel-bin/bin/main
Now in the gdb buffer you must tell gdb where to find source by defining your absolute path to the project root directory (where your WORKSPACE file is):
set directories /home/picaud/.../Cpp
Now the emacs gdb command should work properly and you can debug as usual.
(well this was an easy fix, just a note that maybe can help...)
Related
I am using CMake and GTest to unit test a C++ program. One of my tests uses fopen() to open a file of test data.
I am struggling to figure out how to not get a "No such file or directory" error.
Directory Structure
├── CMakeLists.txt
├── build
├── src
│ └── myProgram.cxx
└── tests
├── CMakeLists.txt
├── data
│ ├── dataset1.txt
│ ├── dataset2.txt
│ ├── dataset3.txt
│ └── dataset4.txt
└── myProgramTests.cxx
Test Code
TEST(test, read_data_file) {
// Open test file
std::FILE *f = fopen("inputs/dataset1.txt", "r");
if (f == NULL){
perror ("Error opening file");
}
fclose(f);
}
This seems simple, but I can't figure out what to put here. I have tried "dataset1.txt", "inputs/dataset1.txt", "tests/inputs/dataset1.txt". What am I missing / is there a way for me into "include" these files via a line in CMakeLists.txt so I can just read them in with one of the strings I tried above?
Summary: How do I properly reference the location of files stored in a tests/data subdirectory within GTest?
Use ctest of cmake. Its add_test command has a useful property WORKING_DIRECTORY that are you looking for.
Paths that do not start with a / are relative to your current working directory, i.e the directory your shell is in when you run the tests.
For example, if your current working directory is the top-level directory of your project, then the relative path to dataset1.txt is tests/data/dataset1.txt
I have a project that uses dub. I want to use an external file vendored into my project, as a dependency. How do I do this? I don't want to have it in my project's source/ dir. I don't want to add it as a dub managed dependency, but I do want to be able to just import xxx.
The package is this one: https://github.com/gianm/d-json , it does not use dub or have a dub.json project file.
Alternative thing: make a third_party directory, put the file in there, then add that to the sourcePaths in your dub config (you'll probably specify both ["third_party", "source"] since the default source will be overridden if you don't list it too.
Convert the package to dub by adding a dub.json file in the root, with the following contents: {"name": "jsonx"}. Create a source folder, and move jsonx.d into it.
Put the folder anywhere you want, e.g. top-level next to your own project.
Add the following dependency to your dub.json:
"dependencies": {
...
"jsonx": {"path": "../jsonx/"}
}
You can now import the package anywhere using import jsonx;.
In conclusion, if your app is in a dir called app, your tree should look like this:
.
├── app
│ ├── dub.json
│ └── source
│ └── myapp.d
└── jsonx
├── dub.json
└── source
└── jsonx.d
I just created my first xcode C++ project. Directory structure looks like the following:
myproject
+-xproject
+-xproject
| +-main.cpp
+-xproject.xcodeproj
Let me describe it (not sure if its necessary). The base folder is myproject, everything inside it was created by xcode.
Instead, I would like have main.cpp outside, like the following:
myproject
+-main.cpp
+-xproject
+-xproject.xcodeproj
Is that possible? How can I get things this way?
Why I want that? Because different IDEs offer different benefits (and debugging in qtcreator might be less straightforward than in xcode, How to debug C++ project using Qt Creator?)
Actually xproject.xcodeproj is a folder which contains:
xproject/xproject.xcodeproj
├── project.pbxproj
├── project.xcworkspace
│ ├── contents.xcworkspacedata
│ ├── xcshareddata
│ │ └── IDEWorkspaceChecks.plist
│ └── xcuserdata
│ └── user.xcuserdatad
│ └── UserInterfaceState.xcuserstate
└── xcuserdata
└── user.xcuserdatad
└── xcschemes
└── xcschememanagement.plist
What I tried (looks like Eljay approach): Open project on xcode, remove xproject/main.cpp and then add myproject/main.cpp. Hit play button and it says build succedded. But also says:
Could not launch "xproject"
LLDB provided no error string.
When I click details I get:
Domain: IDEDebugSessionErrorDomain
Code: 3
Failure Reason: LLDB provided no error string.
User Info: {
DVTRadarComponentKey = 855031;
RawLLDBErrorMessage = "LLDB provided no error string.";
}
ln -s xproject/main.cpp main.cpp
Although I don't like this solution because the original file have to be inside xcode project.
I tried the oposite, but then xcode refuses to work.
I'm trying to compile C++ code into a single binary using .proto files. My current process has 2 steps;
Generate C++ code from 3 .proto files using protoc.
Compile the generated code and my own C++ code into a single .o file.
However, when I try to compile in step 2, the generated code specified outputs as 'com/company/B.pb.h', which fails to be found by the compiler, because the file is in the same directory.
I don't want to manually change the generated code imports as I feel that should be done by protoc, and we also use these proto files for other projects (including generating java code using the same .proto files, which works). Is there a way to specify the generated code's imports WITHOUT changing the proto imports?
EDIT:
Is this an issue with protoc when generating multiple files at once? Should I be using a different command?
I know there are options for java like specifying the package or classname, but I can't find anything similar for C++.
option java_multiple_files = true;
option java_package = "com.company.B";
option java_outer_classname = "B";
Any help is much appreciated. More details below.
Directory structure:
.
├── com
│ └── company # generated code
│ ├── A.pb.cc
│ ├── A.pb.h
│ ├── B.pb.cc
│ ├── B.pb.h
│ ├── C.pb.cc
│ └── C.pb.h
├── Parser.cc
├── Parser.h
└── proto
└── com
└── company
├── A.proto
├── B.proto
└── C.proto
Protoc command: (run from .)
protoc --cpp_out=. --proto_path=proto/ com/company/A.proto com/company/B.proto com/company/C.proto
A.proto snippet:
syntax = "proto3";
option optimize_for = SPEED;
package com.company;
import "com/company/B.proto"; # specified as full path re Google's documentation
...
Parser.cc:
#include "parser.h"
...
Parser.h:
#include "com/company/A.pb.h"
#include "com/company/B.pb.h"
#include "com/company/C.pb.h"
...
G++ command:
g++ -fPIC -Lprotoc -lprotobuf parser.cc -o parser.so
The Error:
fatal error: com/company/B.pb.h: No such file or directory
#include "com/company/B.pb.h"
^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
I never found a way to specify the output for C++ generated code, but I found a way to compile the code correctly without doing janky workarounds, and I think this is the approach I should have taken at the start. Here goes:
Step 1, the generated C++ code stays the same, and it is generated with path includes, and are compiled in the same directory.
Step 2 becomes a make file (we are using Ruby Make/Rake but the concept is the same)
The makefile specifies;
the parser.cc and all the generated .cc files as the sources.
the $LIBS flags -fPIC -lprotobuf (Note the lack of -Lprotoc here, I ran into errors further along the track. Usually about undefined symbols)
the $INCFLAGS ` -I$(srcdir)/com/company ```. (This is a directory for the make file to include in compilation)
the $VPATH $(srcdir)/com/company. (This is a directory for the make file to search.)
This resulted in a .o file being generated for each .proto file, and a .o file for the parser.cc. Then they are combined into a single .so file which can be used as we intended.
Feel free to ask questions if you run into similar issues.
I'm building a "framework" library which one I'm trying to integrate Google Tests. It's a pretty small library, that at the end gives me a .so or .dll file.
When I was starting to tests my library, I found a configuration (details below) that works fine on my CMakeFile at my linux environment. But when I try to run the same project using a MSBuild for MSVC14, it gives me a link error
LINK : fatal error LNK1104: cannot open file '..\src\Debug\foobar.lib'
I'm thinking that my cmake is guessing the lib name wrong (foobar.lib instead of foobar.dll), but I couldn't find why nor how to fix it.
Also, I don't know if this is really the best way for me testing this. What I want is a way to test the whole framework (initializing, creating stuffs, checking returns etc..) without a main.cpp file, and meanwhile start to create the unit tests.
So, my question is.. What am I doing wrong that at the Windows environment the linker does not find the foobar lib built by src/CMakeLists.txt? (I checked, and the lib is created in "src/Debug/foobar.dll", same dir that appears at the error, and works fine)
Also, is my method so wrong that windows just don't wanna deal with? lol I mean, it's wrong to do something like I'm trying to do? It's not that I do not want to make unit tests, which I'll be doing soon, but I really like to build and try my lib without using any external exec binary before I starting to do that.
Thanks!
OBS:
My google tests is working fine both in linux and windows;
I can run the test FooA if I remove the FooBar test, which is linking to foobar lib.
Using my linux environment this configuration works perfectly.
Update:
As #vre suggested, I found the macro __declspec(dllexport) and put it before my FooBar class name and the compilation passed, but it crashes when I run and throws this warning when compiling:
warning C4251: 'FooBar::_impl': class 'std::unique_ptr<FooBar::FooBarImpl,
std::default_delete<_Ty>>' needs to have dll-interface to be used by clients of class 'FooBar'
That's because I have a PImp implementation of the FooBar class. So, I have this:
class __declspec(dllexport) FooBar
{
...
private:
class FooBarImpl;
std::unique_ptr<FooBarImpl> _impl;
}
I don't really know what it means yet. Trying to find out why it crashes.
My project has this file tree:
├── CMakeLists.txt
├── include
| ├── FooBar.hpp
├── src
│ ├── CMakeLists.txt
│ ├── FooBar.cpp
│ ├── FooA
│ │ └── CMakeLists.txt
│ ├── FooB
│ │ └── CMakeLists.txt
│ └── FooC
│ └── CMakeLists.txt
└── test
├── CMakeLists.txt
├── FooBar
│ └── FooBarTest.hpp
├── FooA
│ ├── FakeBar.hpp
│ ├── FooATest.hpp
│ └── mockObj.hpp
My main CMakeLists.txt is like this:
...
set(FOOBAR_INCLUDE "${PROJECT_SOURCE_DIR}/include/FooBar.hpp")
# Include src main CMakeLists
add_subdirectory("${PROJECT_SOURCE_DIR}/src")
# Include tests if enabled
if (test)
add_subdirectory("${PROJECT_SOURCE_DIR}/test")
endif ()
My src/CMakeLists.txt:
...
set(FOOBAR_SOURCES "FooBar.cpp")
# Build
add_library(foobar SHARED ${FOOBAR_SOURCES} ${FOOBAR_INCLUDE})
# Links the library with components.
target_link_libraries(foobar FooA FooB FooC)
And my test/CMakeLists.txt is something like this:
enable_testing()
# Include directories used for testing.
include_directories("${CMAKE_SOURCE_DIR}/src"
"${CMAKE_SOURCE_DIR}/include"
"FooA/"
"FooBar/")
# Include the files for testing.
set(INCLUDE_TESTS "${CMAKE_SOURCE_DIR}/src/FooA/FooA.cpp"
"${CMAKE_SOURCE_DIR}/src/FooA/Bar.cpp")
# Include the test source files.
set(TEST_SOURCES "main.cpp"
"FooBar/JepluTest.hpp"
"FooA/FakeBar.hpp"
"FooA/FooATest.hpp")
# Build
add_executable(foobar-test ${TEST_SOURCES} ${INCLUDE_TESTS})
# Links the library with components. (HERE IS WHERE OCCURS THE PROBLEM)
target_link_libraries(foobar-test gtest foobar)
# Not really important right now
add_test(NAME foobar-test COMMAND foobar-test)
Reformulating and enhancing my previous comments:
You need to export symbols from the DLL on Windows otherwise no import library is created, and that's what MSBuild is complaining about.
First you should add to your FooBar.hpp header the following construct:
#ifdef WIN32
#ifdef FOOBARLIB_EXPORTS
#define FOOBARLIB_API __declspec(dllexport)
#else
#define FOOBARLIB_API __declspec(dllimport)
#endif
#else
#define FOOBARLIB_API
#endif
Later mark your classes, functions and symbols to be exported as follows:
void FOOBARLIB_API foobar(char*)
{
}
In your CMakeLists.txt after creating the shared library target foobar add the line:
target_compile_definitions(foobar PRIVATE FOOBARLIB_EXPORTS)
EDIT:
As #vre commented, these CMake properties are also needed because Windows does not load a DLL located in another folder, causing a crash when it tries to run the executable. So, when a DLL is build and the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable is set, the output library goes to the same directory as the test .exe file.
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)