[Mingw-notify] [ mingw-Bugs-783279 ] assert and -Wl,--subsystem=windows

[SourceForge.net <no...@so...>]

Bugs item #783279, was opened at 2003-08-05 15:56
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=783279&group_id=2435

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Serge Semashko (ssvb)
Assigned to: Danny Smith (dannysmith)
Summary: assert and -Wl,--subsystem=windows

Initial Comment:
Assertion output is not displayed when the program is
compiled as GUI application (-Wl,--subsystem=windows
switch). The program just silently exits on asserts.
The problem is that there is no console to print error
messages to, probably message box can be used in this case?

----------------------------------------------------------------------

>Comment By: Danny Smith (dannysmith)
Date: 2003-08-07 13:56

Message:
Logged In: YES 
user_id=11494

Fixed in binutils CVS.
Apparently, --subsystem windows has been broken for awhile.
Thanks for the simple testcase.

Danny

----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2003-08-07 11:57

Message:
Logged In: YES 
user_id=11494

Luke is correct: it is a binutils bug, not gcc specs.
I have prepared a fix and will submit to binutils after further 
testing.

Danny

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2003-08-07 00:15

Message:
Logged In: YES 
user_id=15438

Modifying the specs file *link section so that it reads:

*link:
%{mwindows:--subsystem windows -e _WinMainCRTStartup}  
%{mconsole:--subsystem console}   %{shared: %{mdll: %eshared
and mdll are not compatible}}   %{shared: --shared
--enable-auto-image-base}   %{mdll:--dll}  
%{static:-Bstatic} %{!static:-Bdynamic}   %{shared|mdll: -e
_DllMainCRTStartup@12}

then uising the -mwindows switch makes this work as expected.

----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2003-08-06 23:54

Message:
Logged In: YES 
user_id=30442

Okay, I was wrong. The bug seems to be in the linker (ld) not 
choosing the correct entrypoint, because it works when I 
pass "-e _WinMainCRTStartup" on the command line.


----------------------------------------------------------------------

Comment By: Serge Semashko (ssvb)
Date: 2003-08-06 19:03

Message:
Logged In: YES 
user_id=541569

Please try this small test program with MSVC 6.0 or Visual
Studio .Net no matter:

#include <windows.h>
#include <assert.h>

int __stdcall WinMain(
	HINSTANCE hInst,
	HINSTANCE hPreInst,
	LPSTR lpszCmdLine,
	int nCmdShow)
{
	assert(false);
	return 0;
}

Compile it:
cl /MD test.cpp /link /subsystem:windows

and run

You will see a message box.

msvcrt.dll is used, not msvcrtd.dll in this example
If you do not believe me, I can post disassembly and
executable structure dump logs here. But I still hope that
you can make some experiments yourself.


----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2003-08-06 13:35

Message:
Logged In: YES 
user_id=30442

Well, the original poster was talking about using assert() not 
_ASSERT(), so I was just pointing out that there is no bug 
with assert() because it works exactly like in MSVC. A 
message box appears only if you use the debugging version of 
the C runtime (msvcrtd.dll), not the library that MinGW 
normally uses (msvcrt.dll). You may try adding -lmsvcrtd to 
your link command but I'm not sure it will work properly 
without modifying the GCC specs file. Alternatively it would be 
fairly trivial to write your own assertion function to display a 
message box, write a log file or do something else useful.

The other debugging functions used by _ASSERT() are only 
present in the debugging library, so this bug report can 
become a feature request to create crtdbg.h and add the 
extra functions to msvcrtd.def (after separating it from 
msvcrt.def).


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2003-08-05 23:18

Message:
Logged In: YES 
user_id=15438

The documentation reference is
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_debugging_assertions.asp

Missing API needs to be added to fix this.

Earnie.

----------------------------------------------------------------------

Comment By: Serge Semashko (ssvb)
Date: 2003-08-05 16:39

Message:
Logged In: YES 
user_id=541569

I'm sorry that I bother you again, but I think that having a
workaround for this problem would be a good idea.

I thought that assert() library function is expected to
produce some VISIBLE results so the end user can mail a
bugreport to me. Forcing users to run the program from rxvt
shell or redirect output from the command line is not a good
idea, it is too complicated for them. Of course, I can
workaround this problem using my own function as assert
replacement, but I thought that assert is expected to be a
portable function just exactly for this purpose and it is
probably worth fixing the compiler library instead.

By the way, GUI applications compiled with MSVC produce
message box on asserts, so doing the same will just add more
compatibility with MSVC.





----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2003-08-05 16:26

Message:
Logged In: YES 
user_id=30442

Assertion functionality is provided by MS in MSVCRT.DLL, and 
this is not a bug. If you want to see stdout/stderr output in a 
GUI program then you need to redirect it, either in your code 
or on the command line. It is also worth noting that you can 
still see the messages in an MSYS rxvt shell. If you want to 
show a message box instead then you'll have to do that 
yourself.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=783279&group_id=2435