<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [PATCH] i965 fails to load miserably on musl libc due to underlinking" href="https://bugs.freedesktop.org/show_bug.cgi?id=93059#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [PATCH] i965 fails to load miserably on musl libc due to underlinking" href="https://bugs.freedesktop.org/show_bug.cgi?id=93059">bug 93059</a> from <a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> Emil Velikov</a> <pre>(In reply to Matt Turner from <a href="show_bug.cgi?id=93059#c1">comment #1</a>) > "miserably" > > > I don't think dri drivers can link directly to libglapi. Cc'ing Emil. In theory there should be no problems when combined with recent enough (don't recall the date/release) xserver/libglx. Priorly libglx was providing the symbols, as it was copying a ton of the gl dispatch from mesa. Nowadays it links against libGL and relies on it to handle things. On the whole topic I've been leaning towards: - folding the static glapi only for special users (osmesa, libgl-xlib) - "forcing" everyone else to shared one and dropping the configure switch - figuring some deprecation period and/or experimentally adding the libglapi link to the dri modules. I'm leaning that foo_dri.so linked with libglapi and old xserver should still work, although that is to be tested. All that aside: albeit not ideal, some libraries need to stay underlinked. Musl devs should seriously reconsider and add support for it.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>