Windows screensaver: Unable to start correctly (0x80000003)

[doublemax]

At least I think doublemaxe's minimal.exe was produced with MSVC?

Yes.

Can MinGW really link the CRT statically? I know that TDM-GCC can but it appears that MinGW requires a couple of its own libraries in addition to linking to that ancient MS CRT. But perhaps there is an option how to do it, wxWidgets do have RUNTIME_LIBS option in makefile.gcc... Are all necessary DLLs in the same folder your executable is?

I think adding RUNTIME_LIBS=static to the build command should work.

[flederwiesel]

I am using TDM-GCC64 but I am in no way a MinGW expert. In fact, it is the first Windows project since a couple of years.

> RUNTIME_LIBS=static
That's one of the things I tried. However, I am not sure, if this really happening, as the binaries do not look as different as I think they should (only three differences in my binary). Maybe I should have a closer look at the building process with gcc on windows.

Is it enough to build wxWidgets as

Code: Select all

mingw32-make -f makefile.gcc SHARED=0 UNICODE=1 BUILD=release RUNTIME_LIBS=static

and then using

Code: Select all

g++ $(shell wx-config --debug=no --static=yes --cxxflags)

respectively --ldflags ... to achive a fully static build? Not sure if --static even necessary using CodeLite, which uses the $WXCFG environment variable to determine wx-config settings.....

> Are all necessary DLLs in the same folder
As for the DLL build, I put the DLLs in the %Sysroot%\System32 folder, just as the binary.

[doublemax]

Code: Select all

g++ $(shell wx-config --debug=no --static=yes --cxxflags)

This step is a little suspicious. Check if the command line parameters that are actually used to build your application are the same as for building the wx libs. If static linking worked, the exe should get significantly bigger.

And until it works, i'd use 32 bit builds during for testing.

[PB]

From my experience, TDM-GCC-64 produces executables with no external dependence without having to specify anything. This can be easily verified with Dependency Walker.

[flederwiesel]

@PB, from what I found all sources suggest the opposite. (See Can I link MSVCRT statically with mingw? and Windows GNU compiler suite without external dependencies). So it seems that e.g. the libmsvcrt.a is merely a so-called import library.

@doublemax:
I built the linker command line by hand and checked, what is actually be considered in the linking process for both, and only *.a files will be linked. These are the statically linked wx libs and the above mentioned import libs for the MS part. Concerning the size comparison: I compared the size after setting RUNTIME_LIBS=static for the wxWidgets build. Maybe there is a misunderstanding and I should have phrased this differently. Once again thinking about the import-libraries it now makes sense to me, that my application remains the same size for both static builds.

I think now it is time to have a closer look at MinGW and its threads implementation, I don't think it's a wxWidgets issue any more, do you?

Regards,
Tobias

[PB]

I'm not sure you understood what import library is, but perhaps I misunderstood you.

Import library means that the code is not linked into the executable, only the references to the functions residing in the external (DLL) library are compiled into it and the DLL will be required on the program startup. As I said before, this is easy to verify with Dependency Walker.

[flederwiesel]

@PB: From my observations, I don't think there is a static CRT for this particular TDM-GCC installation. Dependency Walker seems to confirm this. There are only two libs - C:/TDM-GCC-64/x86_64-w64-mingw32/lib/libmsvcrt.a and C:/TDM-GCC-64/x86_64-w64-mingw32/lib32/libmsvcrt.a - which both pull in msvcrt.dll - even when linking with

Code: Select all

-Wl,-Bstatic

which is imho the gcc counterpart of /MT for the VS toolchain.


Anyway, meanwhile I dived into the disassembled screensaver and found a TDM-GCC patch, which is responsible for the error. "winpthreads/shmem.patch" provides __shmem_winpthreads_grab() which finally calls the int3 that leads to program termination:

Code: Select all

 * The __SHMEM mechanism is for sharing named pointers among the instances of a
 * static library compiled into separate modules (binaries or shared libraries)
 * in one runtime program. It's used in libgcc and libstdc++ to be able to
 * propagate exceptions out of shared libraries even which libgcc and libstdc++
 * are compiled in statically.

static void __w32sp_trap(void)
{
	asm("int $0x3");
}

void* __SHMEM_CONCAT2(SHMEM_NAMESPACE, grab)(const char* name, int size, void (*initfunc)(void*))
{
	int prefix_len = strlen(shmem_version_prefix);
	int name_len = strlen(name);
	int ptr_len = sizeof(void*) * 8;

  ...

	HANDLE hmutex = CreateMutexA(0, FALSE, full_atom_name);
	full_atom_name[prefix_len + 1 + name_len] = '-';
	if (WaitForSingleObject(hmutex, INFINITE) != WAIT_OBJECT_0)
		__w32sp_trap();	// <-- Error 0x80000003

	...

		atom = AddAtomA(full_atom_name);
		if (!atom)
			__w32sp_trap();

	...
}

Let's see whether I get this built to investigate why WaitForSingleObject() fails...