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

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

In any case, it's great news that 2.1.6 is on its way! I've been
slightly worried, as it's more than a year since the last release.

Btw, I've noticed that fceux.com says that 2.1.5 was released 04 June
2010. This should be 02 June 2011, right?

// Alexander

On Sun, Jun 24, 2012 at 5:16 PM, Alexander Toresson
<ale...@gm...> wrote:
> 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