|
From: Alexander T. <ale...@gm...> - 2012-06-24 15:16:40
|
On Sun, Jun 24, 2012 at 4:43 PM, Lukas Sabota <lts...@gm...> wrote: > On Sun, Jun 24, 2012 at 8:25 AM, Alexander Toresson > <ale...@gm...> wrote: >> >> Hello Lukas, >> >> I've managed to devise what may be a workaround for the problem. I >> noticed that the original source distribution worked correctly, while >> my packaged version crashed. I narrowed it down to that I added >> -Wl,--as-needed to the link flags (env.Append(LINKFLAGS= >> ['-Wl,--as-needed'])). The reason I add this is that otherwise, the >> fceux binary will link with libraries which it doesn't use directly >> (but which are used indirectly), like libfontconfig, and that would >> require a direct dependency between the fceux package and those >> packages. >> libGL was one of those libraries that were linked with, but from which >> no symbols were imported from. I found this strange, took a look at >> sdl-opengl.cpp and noticed that all GL symbols were imported at >> run-time. There's no need to import GL symbols at run-time, except for >> symbols from extensions, and you usually link against the core GL >> symbols at compile-time. >> So I modified the code to do that, and magically, the crashes I've >> been having disappeared. At the same time, I could remove a lot of >> lines from the file in question, which is never bad ;) >> I've attached the patch to do this. >> >> // Alexander > > > Hey Alexander, > > Thank you for submitting this patch! I have applied the patch to the > subversion tree (r2539), would you be able to confirm that this resolves the > issue for you on Debian? > > Your contribution is greatly appreciated. This has been irking me for a > while but I have not had the spare time to free up some space and install > debian to try to reproduce. You put the *patches* in "patches welcome". > Thank you for that. > > Let me know how you make out with r2539! Your effort in resolving this bug > is greatly appreciated! > > - lukas < prg318> In the same way it has been irking me, quite a lot. There's many potential users who would be affected by it. There's a big chance that the bug can be reproduced on other distros too, you could try adding "env.Append(LINKFLAGS=['-Wl,--as-needed'])" after the "env.Append(CCFLAGS..." line in SConstruct. Could you try this on Arch? In fact, the Ubuntu package of fceux didn't use -Wl,--as-needed, but after reading https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed it seems like they enable it by default, for all packages. And yes, r2539 now works here, with -Wl,--as-needed enabled. The patch is probably not that magical; my guess is that under some cicumstances, the nvidia drivers don't like when libGL isn't linked to a binary at compile-time, but you probably need to do something more than this to reproduce it, I can't imagine it would only take loading the library at run-time. It would be interesting to pursue this bug and get a smaller test-case for it, if/when I have time for it. Anyway, linking against the core GL functions at compile-time ensures that the binary links against libGL at compile-time, even with -Wl,--as-needed enabled, so it avoids this bug. I have a few more patches in my preliminary debian package, I will probably slowly trickle them upstream. We will see when I manage to upload the package to debian; I need a so-called sponsor for this. I first tried going through the debian maintainer for FCEU, but this hasn't proved fruitful, as he seems to be very busy, and usually doesn't even reply to your e-mails. // Alexander |