Without it, following error occurs on Fedora 15 when compiling for x86_64: /usr/bin/ld: npplayer-npw-player.o: undefined reference to symbol 'dlsym@@GLIBC_2.2.5' /usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line /lib64/libdl.so.2: could not read symbols: Invalid operation collect2: ld returned 1 exit status Fedora already has a patch that adds -ldl to LDFLAGS Signed-off-by: Pavel Roskin <email@example.com>
In case a plugin attempts to check this (unlikely as no browser implements it yet) and avoid NULL checks on all the entry points, we shouldn't crash. Also, for correctness, even if the browser supports it, a browser + nspluginwrapper combination doesn't.
To say nothing of atomicity, lots of Bad Things happen when you replace libraries in-place. gdb apparently gets upset at you, and you get random crashes in programs which have the library loaded. Evidently libdl.so can't even handle it. It's unspecified whether changes to a file mmapped as MAP_PRIVATE are visible to the process. Fixes #35.
Browsers are supposed to set it all the time, if we take what Firefox and Chrome do as the spec (which is as reasonable as anything). May as well apply the workaround everywhere instead of assuming only Flash needs it. Reported-By: Stanislav Brabec <firstname.lastname@example.org>
… signals. Signed-off-by: Stanislav Brabec <email@example.com>
This is a bit of an embarrassing bug. The allocated size of the array and the number of elements are not always the same. Reported by Fridtjof Busse.
See bug #29. Reported by Matthias Dahl.
Unfortunately, while Konqueror pretends to have an Xt event loop, it is completely non-functional. Block hooks will not run, because it is a Qt event loop polling Xt. Work procs also do not work because Xt does not report them in XtAppPending. A timeout should, in theory, work, but Konqueror doesn't even enable its Xt bridge most of the time! If the plug-in requests XEmbed (as Flash does), a PluginHostXt is never created and XtEvents::enable is never called. Instead of fighting all this, just use the glib event loop. They have a bridge and Qt uses the glib event loop these days anyway. The only reason it used to work is because, not supporting windowless plug-ins, most of communication was from browser to plug-in. Requests would just get queued up and (with luck) not time out. With the new delayed sync mechanism, we are unable to register the delayed sync and instead the plug-in hangs.