How can I change the output directory in Google glog?
I only found google::SetLogDestination(google::LogSeverity, const char* path)
tried it with:
google::SetLogDestination(ERROR, "C:\\log\\error.log);
google::InitGoogleLogging("Test");
LOG(ERROR) << "TEST";
but nothing was written!
Btw.: if you suggest another lightweight, easy to use and thread safe library please let me know!
Thx for any help!
You can also do one of the following:
Pass the log directory as a commandline argument as long as you have the GFlgas library installed:
./your_application --log_dir=/some/log/directory
If you don't want to pass it in the commandline and instead set it in the source:
FLAGS_log_dir = "/some/log/directory";
If the Google gflags library isn't installed you can set it as an environment variable:
GLOG_log_dir=/some/log/directory ./your_application
Here is the test what I did, you may try it,
#include <glog/logging.h>
using namespace std;
int main(int /*argc*/, char** argv)
{
FLAGS_logtostderr = true;
google::SetLogDestination(google::GLOG_INFO,"c:/lovelyGoogle" );
google::InitGoogleLogging(argv[0]);
LOG(INFO) << "This is INFO";
LOG(WARNING) << "This is WARNING";
LOG(ERROR) << "This is Error";
system("pause");
return 0;
}
Tested under Visual studio 2012, google-glog 0.3.3 on Windows 7.
It generated lvoelyGoogle20131016-141423.5160 on my C driver.
If you set FLAGS_logtostderr = false, the log file will not be generated,
I believe you have already read this (well, I have no comment on it)
hope this helpful, good luck.
PS: I have tested on QtCreator (Qt5.1) as well on Windows7, nothing output. I have no idea how to fix it now.
I use this:
fLS::FLAGS_log_dir = "c:/Documents/logs";
In my terrifying experience with this library I came to see that this flag FLAGS_log_dir and this function google::SetLogDestination() compete with each other. Wonderful.
I learned that you can use either but not both.
option 1: use flags
FLAGS_log_dir=/path/to/your/logdir
google::InitGoogleLogging(exec_name.c_str());
and generate a bunch of files named your_exec.some_number.machine_name.log.log_severity.... and their respective symbolic link inside the /path/to/your/logdir. A pair of files will be generated for each log_severity you have used in your program (INFO, WARNING, ERROR, FATAL). Fun fact: INFO files contain everything, WARNING files contain everything from warning downwards, and so on. God knows why these symlinks are needed.
option 2: use file names
std::string log_dir = "/path/to/log/dir";
for (int severity = 0; severity < google::NUM_SEVERITIES; ++severity) {
std::string fpath = fs::path(fs::path(log_dir) / fs::path(exec_name).filename());
google::SetLogDestination(severity, fpath.c_str());
google::SetLogSymlink(severity, "");
}
google::InitGoogleLogging(exec_name.c_str());
where fs is the filesystem library of c++17. This is send all logs to the same file (just one, not many) and finally remove that annoying symbolic link.
Related
I have already set up my Msys2 and installed mingw-w64-x86_64-boost on it.
I provided a minimal example of c++ with boost which I will build using the command g++ main.cpp -o main.exe -lboost_program_options-mt:
#include <boost/program_options.hpp>
#include <string>
#include <iostream>
namespace po = boost::program_options;
int main(int argc, char** argv) {
// Arguments will be stored here
std::string input;
std::string output;
// Configure options here
po::options_description desc ("Allowed options");
desc.add_options ()
("help,h", "print usage message")
("input,i", po::value(&input), "Input file")
("output,o", po::value(&output), "Output file");
// Parse command line arguments
po::variables_map vm;
po::store (po::command_line_parser (argc, argv).options (desc).run (), vm);
po::notify (vm);
// Check if there are enough args or if --help is given
if (vm.count ("help") || !vm.count ("input") || !vm.count ("output")) {
std::cerr << desc << "\n";
return 1;
}
std::cout << "The rest of the code will be here"; <- Indication that it is working
}
It compiles and links without logging an error when I ran the said command, but now when I try to run it, it just doesn't execute properly.
At the least, I was expecting to see the text The rest of the code will be here to be outputted to the console when I ran it as an indication that it is being executed, however it didn't output it:
I tried to debug it, but GDB itself can't debug it
This is what it looks like in the VSCode Debug Console:
Running a separate GBD on the command line:
With all of that said, I am assuming that this is a linker error given that the resulting executable is being outputted by the compiler. What are your thoughts regarding this problem?
Yooo! I fixed the issue.
I first tried to run it on a fresh virtual machine to cross out the possibility that this issue is caused by my current environment. Surprisingly enough, it worked perfectly fine on the virtual machine. Knowing that it only happens in my current environment, I did proceed to make the following changes ().
Complete reinstallation of msys2 in my system, (you can disregard this step because I'm pretty sure that step 2 is enough)
Moving up the priority of the msys2 path in the environment variables.
To do step 2 follow these steps (windows 10):
Search for "Edit environment variables for your account" in the search bar
Under "User variables" select variable "path" and click edit
Now, select the item for the bin path of the mingw on Msys2
Once you've selected it now, move up its priority as shown below.
Press ok, then restart the terminal, and it should work now
I'm trying to get into SDL2 in C++ and I have followed all the steps in a variety of YouTube tutorials. I am using vs2019, and every time I try to run anything I get this error: Failed to locate: "CL.exe". The system cannot find the file specified.
For example, it happens when I try running this code:
#include "SDL.h"
#undef main
#include <iostream>
int main() {
int x = 1;
std::cout << "Hello World!\n";
std::cin.ignore();
return 0;
}
I have followed all of the steps, but nothing seems to work. Similar questions have been asked, but their solutions don't work for me. I'm just running it in the editor. Can anybody help me?
You need to run VCVARSALL.BAT for Visual studio 2019 in the console for making cl.exe available.
Alternatively you can run "Developer Command Prompt for VS 2019" from the Start menu and run cl.exe there (after changing the appropriate working directory to one containing your code).
I am going to post this as a potential answer, pending OP’s clarification to what he means by “running it in the editor”.
MSVS does not install with the C and C++ compiler and libraries unless you specifically ask for them. To install them you must re-run the installer. You will eventually get a screen with a lot of different options on it. It is a tabbed page with “Workloads”, “Individual Components”, and “Language Packs” at the top.
Find and make sure that you select both:
“Universal Windows Platform development”
“Desktop development with C++”
Continue as usual. The installer will update MSVS with the ability to compile C and C++ programs.
You can also read Microsoft’s instructions.
I have this well known c++ program in my Visual Studio 2015 Prof:
#include <iostream>
int main(int argc, char* argv[]) {
std::cout << "Hello World!" << std::endl;
return 0;
}
As expected, it shows "Hello World!" if I hit Ctrl+F5. However, if I go to the directory within an cmd.exe and execute the HelloWorld.exe file, it doesn't show anything as output, but does quit (I can type in again).
According to a similar question I checked the settings of the project but I did not need to change anything, the Configuration Properties -> Linker -> System -> SubSystem already is at Console (/SUBSYSTEM:CONSOLE).
Flushing the std::cout also didn't help anything. It is reproducable on every freshly created project of VS2015 on my Win 7 64-bit machine and seems to be presistent after rebooting.
What is wrong with my IDE / settings?
After the hint of #Scheff I threw the exe file into "Dependency Walker". It gave me a missing UCRTBASED.DLL and lots of second and third level missing dlls (I think this is usually the case on every application?).
I somehow think my (recently installed) anti virus did interfere with that, because it shows some messages in the log regarding my HelloWorld.exe.
However, deinstalling anti virus and restarting machine did the trick. I can finally see Hello World! on cmd.exe.
I try to run diagnostic tools in Visual Studio 2015 Community for a test project.
My code:
#include<iostream>
int main()
{
for (;;)
{
std::cout << "Hello, World!";
getchar();
}
return 0;
}
I use x64 platform in configuration Debug. The Window Diagnostic Tools fail unexpectedly, saying the following:
The diagnostic tools failed unexpectedly. The Diagnostic Hub output
in the Output window may contain additional information.
Diagnostic Hub:
The scratch directory cannot have a trailing junction point.
What does it mean? How do I correct this error?
It's complaining that the "scratch directory" isn't actually a directory but some kind of reparse point. Reparse points are used to implement various NTFS file system features, notably junction points and symbolic links.
I'm not sure which directory the scratch directory is supposed to be, but my guess is that it's your TEMP directory (normally something like C:\Users\ROSSRI~1\AppData\Local\Temp) and you've done something like moved it to another drive using a junction point or symbolic link. You can check to see if your TEMP directory isn't really a directory by entering the following command in the Windows command prompt:
for /d %i in ("%TEMP%") do #echo %~ai
If it prints d-------- then it's a normal directory, but if it prints d-------l then it's a junction point.
Assuming I'm correct the solution would be either to move the TEMP directory back or point the TEMP and TMP environment variables to the location where you moved it.
Just :) restart your computer (yes nothing else helped me).
I'm trying to compile an run a very basic program given below (test.cpp) which calls the OpenNI class. You can see the files and dirs they're in here. Sorry that some characters screws up a little bit in the browser's encoding. I'm using the linux command: tree, if you know a better command tell me and I will update it.
File Structure
I'm following the guide here, see "GCC / GNU Make".
#include < stdio.h >
#include < OpenNI.h >
using namespace openni;
int
main ( void )
{
Status rc = OpenNI::initialize();
if (rc != STATUS_OK)
{
printf("\nInitialize failed\n%s\n", OpenNI::getExtendedError());
return 1;
}
printf("Hello, world!\n");
return 0;
}
Here is what I'm running in the command line to compile it (gcc 4.7.2):
gcc test.cpp -I../OpenNI-2.0.0/Include -L/home/evan/Code/OpenNi/Init -l OpenNI2 -o test
This works fine but when I run ./test I get the following error:
Initialize failed
DeviceDriver: library handle is invalid for file libOniFile.so
Couldn't understand file 'libOniFile.so' as a device driver
DeviceDriver: library handle is invalid for file libPS1080.so
Couldn't understand file 'libPS1080.so' as a device driver
Found no valid drivers in './OpenNI2/Drivers'
Thanks, any help would be much appreciated.
Instructions from your guide says, that
It is highly suggested to also add the "-Wl,-rpath ./" to your linkage command. Otherwise, the runtime linker will not find the libOpenNI.so file when you run your application. (default Linux behavior is to look for shared objects only in /lib and /usr/lib).
It seems you have exactly this problem -- it can not find some libraries. Try to add proper rpath (seems to be /home/evan/Code/OpenNi/Init/OpenNI2/Drivers in your case) to your compilation string.
I had the same issue after compiling this little "Hello World" with Eclipse and trying to run it in the command line.
The "Wl,-rpath=./" thing did not work for me.
As also discussed here it worked for me after setting some env. variables before execution:
export LD_LIBRARY_PATH="/path/to/OpenNI2:$LD_LIBRARY_PATH"
export OPENNI2_DRIVERS_PATH="/path/to/OpenNI2/Drivers"
export LD_LIBRARY_PATH="/path/to/OpenNI2/Drivers:$LD_LIBRARY_PATH"
Somewhere I got the info that the first two lines should be enough but it was the third line which is important. I does also work just with the third line.