One of my Win10 desktops has very odd problem with visual c++ compiler (vc142 toolchain/msvs2019, Win10): it opens new console window each time when c++ compiler (cl.exe) is started by any GUI app.
as the compiler is in the use by IDEs (e.g. VisualStudio, CLion, QtCreator etc) , it's very useless because output of the compiling can't be caught by callee (IDE) and IDEs don't show any compilation output , especially compile message in case of error. Obviously these IDEs do this indirectly , via build systems like msbuild or cmake . anyway , the problem is there.
So NMake or MSBuild can't be used correctly , because those ones run cl.exe in separate window. I have to run a build procedure from command line manually to see the error message.
the same toolchain can be used correctly on other Win10 hosts. I don't see the difference...
any idea why it 's happening and how to fix?
P.S. probably this is not a problem of cl but some windows terminal settings... or even security issues (I'm not an admin on that host)
For us, it was a corporate spyware program, BeyondTrust/PowerBroker for windows that was somehow making cl.exe misbehave.
PowerBroker basically takes over the UAC control and forces apps to run in privileged mode or non-privileged mode, etc. I'm not sure the mechanism but somehow it interfered with cl.exe writing to stderr, or ninja.exe's ability to redirect stderr to itself, or ninjas ability to pipe it somewhere or something.
Anyways, putting a whitelist rule in (or killing the beyondtrust service) made VSCode calling cmake calling ninja calling cl.exe behave properly.
EDIT: More details: cmake.exe, ninja.exe, and cmd.exe are the processes that need to get exempted from BeyondTrust's PRIVMAN to make cmake builds from VSCode function without popups.
Related
I am a freshman on Qt Designer.
Recently, I've used Qt creator create my own Qt project, which has been available to serial port. However, when I tried to debug my project, it always showed my with the following message, especially when there were breaks in my projects:
Error: The GDB process teminated.
I am very depressed. I have been getting stuck for several days.
If anyone could give me some instructions, more thanks would be given!
Thank you!
There can be different reasons, with different solutions;
(Below will list those most commonly causing this for me.)
#1 Toolchain
It's maybe related to your toolchain, for example I experienced similar issues, where I was compiling my code with latest MingW, but Qt was built with a little older MingW compiler.
I searched everywhere for the specific MingW, that which Qt was built with, but could not find that.
The only solution for me was to rebuild Qt from scratch (and fix all build errors).
#2 Permission
Another time, I was trying to attach debugger to an App running as root.
After running IDE (and by that the debugger) as root, things started to work.
But sometimes, following below #3 was required, too.
#3 Working Directory
Apps may load dependencies based on current-working-directory, for this case:
If you want to attach-debugger to already running root App:
We need to change the way IDE is launched, for example, open the terminal and cd to where the App requires us to (like directory containing the executable), then launch IDE from terminal (using it's path).
This may only be required when attaching to App(s) running as root, and even there not for all IDEs (but was required for QtCreator v4.x at least).
If you don't attach:
Simply change IDE configurations, I mean, most IDEs allow you to select working-directory (like QtCreator does), first do that and then start debugging.
I was having an issue with a C++ program where when I ran the .exe the program would run and my window for the program would open, but the console would be open on the desktop in the background. I did a google search and found that compiling with the -mwindows command as an argument, removes the console. Which it did. But I'm unsure of what it actually does and I am curious.
It behaves exactly the same as the /subsystem:windows switch described on MSDN.
Basically, it sets the entry point to WinMain (or wWinMain) instead of main (or wmain), which results in no console window and some Win32 startup code running to create the arguments passed to WinMain. As Neil says, it does not prevent or enable anything you can't do without it.
A similar switch is -municode to switch between main/WinMain and wmain/wWinMain, which is not mirrorred by the Microsoft tools. These seem to automagically select the one you use).
It says that your application is one using the Win32 API that doesn't need a console window. You use this option when you are writing Windows GUI applications, DLLs and the like, although a console window can be useful when debugging these kinds of applications. Even with this option, you can explicitly create a console window, should your application need one dynamically and, contrariwise, you can call Win32 GUI APIs from a console application.
In Code::Blocks 20.03 (uses the MinGW-W64 gcc compiler project) the project target ( bin/Release ) compiles with -mwindows and the project target ( bin/debug ) compiles without -mwindows. The debug target not only has debugging information in the executable, but it runs with the console window exposed in the background. This is 'highly' useful for debugging, since your app can write to the console debugging messages while your gui app is processing... like an active debugging log.
Obviously the console is ugly for release targets. In Code::Blocks the switch -mwindows is set indirectly in the Project properties under the 'build targets' the bin/debug build target is specified as console app, while the bin/release target is specified as gui app.
Back in the day (maybe eight years ago) there was a catch-22; -mwindows was necessary to link the Win32 api (but no console). If you wanted a console AND the Win32 api it didn't work easily; fortunately this is not an issue today... you can mix and match. I generally build my release targets without the console; and I build the debug targets with the console, and I use the console for debugging copiously.
marcus
The dev environment in question consists of:
Windows 7
MinGW (g++)
CMake
Qt Creator
The problem is that Qt Creator, a lovely IDE as far as I can tell, does not display programs' command-line output. It seems to have its own proprietary debug pane, but it doesn't give me, for example, runtime errors. It just tells me that the program has failed and gives me the exit code. I'm using Creator only for its C++ capabilities, and not using Qt in any way, so the proprietary pane is useless to me.
So I ask this: Can something be done? Am I missing something really, stupidly obvious like a built-in command line? Or, if not, can I at least use some filthy and/or repulsive hack to get it to display the Windows command prompt upon running a program?
Last thing; I did do some research, and found a way to edit the Qt project file to display the prompt, but... I'm using CMake, not Qt projects. So that doesn't answer my question. If I can do something similar with CMakeLists.txt, that would be wonderful. But Google has failed me on that front, so I'm not holding out too much hope.
EDIT:
I'm specifically worried about runtime errors. cout and printf are rerouted to Qt Creator's window, so that's fine. I don't get runtime errors unless the debugger catches them, and the frequency of that is less than ideal.
Windows GUI programs don't have standard output.
In Windows there are two possible entry points in the standard runtime. The console one and the windows one. The console one will inherit console window from parent process or create a new one and connect the standard input/output/error streams to it, while the windows one will leave them unconnected unless they were explicitly redirected by the invoking process. A Qt application is (probably; you could have console Qt-Core application) a GUI application and Qt Creator (nor any other Windows IDE) does not redirect the output explicitly. Therefore the standard output is not open at all and the writes are being discarded.
However windows have separate logging facility for debugging purpose. This is what you see in the debug window. You can write to it using the native OutputDebugString API. I am sure you can also direct the Qt debug log there.
Note, that when it tells you the program has exited with status 0, it means the program ran, which in turn means it compiled successfully and thus there were no errors from g++. There may have been warnings, in which case you should see them in the appropriate other window. Compiler and program output are different things; the IDE does read the compiler output.
When programming in eclipse (c++), I would like to just hit f5 (run) and have the project I'm working on save, build and (if there are no errors) run. If there are errors I want it to show the problems window and stop.
This all works at the moment except for the part where it shouldn't run when there are errors.
Is there a way to make eclipse never run the project when there are errors? Perhaps with an addon?
EDIT: Forgot to mention the prompt... The prompt does show but I want it to not show at all. If you look at the preference window you'll see that there's no 'never' option, there is one for all the other options but not for the 'launch if project contains errors'.
By default, Eclipse CDT does not run code with build errors, but maybe you have checked the option Always launch without asking checkbox.
You should go to Windows menu->Preferences->Run/Debug->Launching->Continue launch if project contains errors and check Prompt option instead of Always. Using this, Eclipse CDT will prompt you if errors exists during building or launch your binary if it has been compiled without errors.
I'm trying to get Eclipse CDT (64 bit eclipse) working on Windows 7 with GCC. When I first got GDB working (that was a challenge in itself), running the program in debug mode was the only way I got output. Running it normally didn't give any console output. After hours of googling, I figured out that if I added C:/cygwin/bin to my environment path in eclipse, I could get output when running the program normally. Then I ran it in debug mode and there was no output. I tested this a couple of times to make sure it was the addition of the path causing the problem. This is the program I was running,
#include <iostream>
using namespace std;
int main() {
cout << "Hello World!" << endl;
return 0;
}
So how can I get both normal and debug modes working, and why did I have to include that path in the first place (it's already in my cygwin path and why does CDT need it?) ? Also, why is it that if I add a path to my Run configurations it will also be added to my Debug configurations?
From wiki eclipse:
In Eclipse CDT on Windows, standard output of the program being run or debugged is fully buffered, because it is not connected to a Windows console, but to a pipe. See bug 173732 for more details. Either add flush calls after every printf or add the following lines at the start of the main function:
setvbuf(stdout, NULL, _IONBF, 0);
setvbuf(stderr, NULL, _IONBF, 0);
I don't think I can answer everything but I use exactly the same set-up as you and I've had to deal with quite a few issues like this (I'm wondering if you had trouble how to juggle using the 32-bit/64-bit JVM and Internet browsing)!
The cygwin/bin path must be specified because that is where gcc, gdb and all the other cygwin tools and dlls are located (I'll assume you're using cygwin flavour of gcc rather than MinGW flavour). I believe you must specify it in the Windows environment (using a win32 file path) because Eclipse is running using the Windows JVM and therefore deals with win32 paths. Consequently, it doesn't matter that cygwin/bin is added to the PATH variable in the cygwin environment. CDT is looking for cygwin using Eclipse, and Eclipse needs to find cygwin1.dll from Windows.
I might be totally wrong, but if I had to guess I would say that you need to make absolutely sure you have properly set the PATH environment variable correctly for both configurations.
One thing to note is that in Eclipse there is no difference between a configuration shown in the Debug Configurations window and one with the same name in the Run Configurations window. The only difference between the two windows is that one will run the program without using a debugger and has tabs for setting debug settings. Therefore it's no surprise that changing settings in one will also affect the other.
As you may know, for many projects the build system is set up to produce two (sometimes more) sets of binaries: one with debugging info/symbols (DEBUG) and one without (RELEASE). In this case, you normally have two configurations in Eclipse: one to run the DEBUG binary and one to run the RELEASE binary. Both of these will show up in both the Debug Configurations window and in the Run Configurations window. The point is that you can run DEBUG either with or without gdb, but RELEASE cannot be used by gdb.
That said, I'm not sure why adding the correct path to the run configuration would stop the DEBUG binary from outputting to the console. I suspect something else is going on here, perhaps a mismatch of debug info and debugger.
To (hopefully) answer your question as to how to get both configurations working, go the whole-hog and just add C:\cygwin\bin; to the Windows PATH environment variable. I'm guessing that will allow both to work. I'll assume you know how to do that but please post a comment if not.
The other thing to try would be to compile and run the program from a cygwin shell. If it works there it's probably a safe bet that your PATH environment variable is not set correctly when using eclipse.
Hope that helps!
Adding the Path was correct before gdb 7.3. Now when I add the path I can no longer use breakpoints as it cannot find the dll files as they are no longer part of the path. To fix this you can easily add the entire path from the environment by following these instructions.
left click the project
enter the RUN/DEBUG settings for the project
select the executable
click edit
select Environment Tab
click Select...
scroll down to Path (Case sensitive)
check mark Path
press OK
press OK
press OK
You can see the dll problem as it appears in the gdb console
error,msg="During startup program exited with code 0xc00000be."
or
error,msg="During startup program exited with code 0x00000135."
and you may get an error window pop up saying it could not clear the breakpoint
You need to set up linker
I am using MinGW.
Follow below steps.
Goto Project > Properties > C/C++ Build > Settings > Tool Settings (Tab) > MinGW C++ Linker (Option) > Add Command (g++ -static-libgcc -static-libstdc++) (default command is only g++)
Don't debug or run C or C++ applications from inside Eclipse if they target Cygwin. TK link to "you're gonna have a bad time" meme.
There are problems with Cygwin stdout/stderr that don't show up if you run the programs from the normal Cygwin console (where you would be running bash), but they do show up in pretty much every other way you can run them.
The normal way that programs run other programs in Linux and other posix-supporting environments is to reroute the i/o to a pty. Cygwin can't support pty's 100% in Windows.
Some of the problems can be ameliorated by the setvbuf calls in #infoartenovo's answer.
A flip side of this problem is that applications written to use Windows' Console API don't work well in ptys.
We are all collateral damage in an unwinnable war.
http://cygwin.com/ml/cygwin/2011-12/msg00236.html
https://code.google.com/p/mintty/issues/detail?id=56