Fails to call SDL_InitSubSystem from plugin (Was: State of SDL2 in MXE)

Hm, now I have the problem that I cannot initialize subsystems from loaded
plugins in SDL2 anymore when using MXE (cannot test MSVC).

if(SDL_InitSubSystem(SDL_INIT_AUDIO | SDL_INIT_TIMER | SDL_INIT_JOYSTICK |
   SDL_INIT_HAPTIC | SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE) < 0)
{
    fprintf(stderr, "Unable to init SDL: %s\n", SDL_GetError());
    return 1;
}

works in the SDL_main function. But when done from a loaded DLL (plugin) it
just says:

“Unable to create Helper Window Class: Class already exists.”

or (depending on whether using SDL_InitSubSystem/SDL_Init)

“Application didn’t initialize properly, did you include SDL_main.h in the
file containing your main() function?”

It worked fine in the past with SDL1.2 and works fine with SDL2 under linux.
The plugin was loaded with LoadLibrary+GetProcAddress and compiled with i686-
w64-mingw32-gcc from mxe 8e7faf84df19346635ffff6c78cabc6a3d4afbc1.

So, I am now completely unsure how I should fix the SDL_MainIsReady from the
view of the plugins. Maybe, if the SDL gurus don’t know: MXE is compiling
everything as static libraries. This maybe doesn’t work on windows when the
state of SDL should have been shared between main program and plugin. But now
it is impossible to write a plugin with SDL support because I cannot
initialize the subsystems–
Franz Schrober

as MXE is linking statically, you are loading sdl twice - once the
statically linked sdl of your main program, and once the dll. I suppose
the linux build was linked dynamically, and not statically. If you would
link SDL statically to your main program, you should also get the same
error on linux.

A possible solution here would e.g. be to only give function pointers to
your plugin dll and not linking the dll to SDL at all. I’m of course not
sure whether that would work in your particular use case. But linking
two times and relying on a shared state might lead to a lot more
trouble. The SDL_MainIsReady is only the first visible thing.

Regards
MartinAm 25.06.2013 13:38, schrieb Schrober:

On Tuesday 25 June 2013 12:58:57 Schrober wrote:

Just as info for the developers: This regression was introduced in rev
cd5516b9263d - reverting it fixes the problem for me. Attached are both
files
Here is the output of some debug patch (attached) on MXE (windows):

DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 004C8720
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 004C8720
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(0) 652C99A0

The first two are from the main program and the last one is from the plugin
loaded by the main program. And on linux it looks like:

DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008

Just as info for the developers: This regression was introduced in rev
cd5516b9263d - reverting it fixes the problem for me. Attached are both filesOn Tuesday 25 June 2013 12:34:07 Schrober wrote:

Hm, now I have the problem that I cannot initialize subsystems from loaded
plugins in SDL2 anymore when using MXE (cannot test MSVC).

if(SDL_InitSubSystem(SDL_INIT_AUDIO | SDL_INIT_TIMER | SDL_INIT_JOYSTICK

| SDL_INIT_HAPTIC | SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE) < 0) {
fprintf(stderr, “Unable to init SDL: %s\n”, SDL_GetError());
return 1;
}

works in the SDL_main function. But when done from a loaded DLL (plugin) it
just says:

“Unable to create Helper Window Class: Class already exists.”

or (depending on whether using SDL_InitSubSystem/SDL_Init)

“Application didn’t initialize properly, did you include SDL_main.h in the
file containing your main() function?”

It worked fine in the past with SDL1.2 and works fine with SDL2 under linux.
The plugin was loaded with LoadLibrary+GetProcAddress and compiled with
i686- w64-mingw32-gcc from mxe 8e7faf84df19346635ffff6c78cabc6a3d4afbc1.

So, I am now completely unsure how I should fix the SDL_MainIsReady from the
view of the plugins. Maybe, if the SDL gurus don’t know: MXE is compiling
everything as static libraries. This maybe doesn’t work on windows when the
state of SDL should have been shared between main program and plugin. But
now it is impossible to write a plugin with SDL support because I cannot
initialize the subsystems


Franz Schrober
-------------- next part --------------

This file is part of MXE.

See index.html for further information.

PKG := sdl2
$(PKG)_IGNORE :=
$(PKG)_CHECKSUM := ff1853d589ad2974e43154e977ed554f71a5a9d2
$(PKG)_SUBDIR := SDL2-$($(PKG)_VERSION)
$(PKG)_FILE := SDL2-$($(PKG)_VERSION).tar.gz
#$(PKG)_URL := http://www.libsdl.org/release/$($(PKG)_FILE)
$(PKG)_URL := http://www.libsdl.org/tmp/release/$($(PKG)_FILE)
$(PKG)_DEPS := gcc libiconv

define $(PKG)_UPDATE
$(WGET) -q -O- ‘http://hg.libsdl.org/SDL/tags’ |
$(SED) -n ‘s,.release-([0-9][^<]).*,\1,p’ |
head -1
endef

define $(PKG)_BUILD
$(SED) -i ‘s,-mwindows,-lwinmm -mwindows,’ ‘$(1)/configure’
cd ‘$(1)’ && ./configure
–host=’$(TARGET)’
–disable-shared
–prefix=’$(PREFIX)/$(TARGET)’
–enable-threads
–enable-directx
$(SED) -i ‘s,defined(__MINGW64_VERSION_MAJOR),defined(__MINGW64_VERSION_MAJOR) && defined(_WIN64),’ ‘$(1)/include/SDL_cpuinfo.h’
$(SED) -i ‘s,-XCClinker,’ ‘$(1)/sdl2.pc’
$(SED) -i ‘s,-XCClinker,’ ‘$(1)/sdl2-config’
$(MAKE) -C ‘$(1)’ -j ‘$(JOBS)’ bin_PROGRAMS= sbin_PROGRAMS= noinst_PROGRAMS=
$(MAKE) -C ‘$(1)’ -j 1 install bin_PROGRAMS= sbin_PROGRAMS= noinst_PROGRAMS=
ln -sf ‘$(PREFIX)/$(TARGET)/bin/sdl2-config’ '$(PREFIX)/bin/$(TARGET)-sdl2-config’
endef

$(PKG)_BUILD_i686-pc-mingw32 =
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl2-1-revert_cd5516b9263d_init_check.patch
Type: text/x-patch
Size: 3795 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130625/b4ab4dde/attachment.bin

Here is the output of some debug patch (attached) on MXE (windows):

DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 004C8720
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 004C8720
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(0) 652C99A0

The first two are from the main program and the last one is from the plugin
loaded by the main program. And on linux it looks like:

DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008On Tuesday 25 June 2013 12:58:57 Schrober wrote:

Just as info for the developers: This regression was introduced in rev
cd5516b9263d - reverting it fixes the problem for me. Attached are both
files


Franz Schrober
-------------- next part --------------
A non-text attachment was scrubbed…
Name: check.patch
Type: text/x-patch
Size: 1009 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130625/2f9c6e62/attachment.bin

Yes, this was what I assume. Giving functions pointers around is not possible.
But it seems to be ok to modify mxe to make shared objects. And btw. I ran in
the next problem when I tried to create an SDL window from a plugin (endless
recursion which trashed the stack).On Tuesday 25 June 2013 14:04:02 Martin Gerhardy wrote:

Am 25.06.2013 13:38, schrieb Schrober:

On Tuesday 25 June 2013 12:58:57 Schrober wrote:

Just as info for the developers: This regression was introduced in rev
cd5516b9263d - reverting it fixes the problem for me. Attached are both
files

Here is the output of some debug patch (attached) on MXE (windows):

DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 004C8720
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 004C8720
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(0) 652C99A0

The first two are from the main program and the last one is from the
plugin
loaded by the main program. And on linux it looks like:

DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008
DDDDDDDDDDDDDDDDDDDDDDebug checking if MainIsReady(1) 0x7f7815241008

as MXE is linking statically, you are loading sdl twice - once the
statically linked sdl of your main program, and once the dll. I suppose
the linux build was linked dynamically, and not statically. If you would
link SDL statically to your main program, you should also get the same
error on linux.

A possible solution here would e.g. be to only give function pointers to
your plugin dll and not linking the dll to SDL at all. I’m of course not
sure whether that would work in your particular use case. But linking
two times and relying on a shared state might lead to a lot more
trouble. The SDL_MainIsReady is only the first visible thing.


Franz Schrober