#14 rpmlint says: shared-lib-calls-exit

VirtualGL (13)

This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the
error, reporting it to the user, closing files properly, and cleaning up any
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the


  • DRC

    DRC - 2012-02-21
    • status: open --> closed-wont-fix
  • DRC

    DRC - 2012-02-21

    Please understand that VirtualGL is not just "a library." It's an interposer. It is specifically designed to be preloaded into an application, not called directly by an application. Thus, it has to do things that wouldn't necessarily be kosher for an API library. That includes, for instance, not using versioned symbols, and several distro maintainers have blindly rejected VirtualGL on this basis alone, completely missing the point of what VirtualGL is intended to do.

    This seems like a similar type of complaint. VirtualGL has always called exit(), and there are good reasons why. A quick examination of the code would reveal these. There are certain things that are non-recoverable in VirtualGL. For instance, if the user specifies that the VGL Transport should be used but a connection with VGLclient cannot be established, there is no way to recover from that. We have the choice of calling exit() or just letting the application continue to think it's running, but nothing will work properly within it. I think you'll agree that exiting is the more friendly approach here. VirtualGL calls exit() only for errors that are related to VirtualGL itself. For errors that are related to the underlying OpenGL/GLX/X11 subsystems, VirtualGL passes those back to the application.

  • DRC

    DRC - 2014-08-05
    • Status: closed-wont-fix --> closed-wont-implement

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks