Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Alexander T. <ale...@gm...>]

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