Summary: | libOSMesa / libdricore not linked well | ||
---|---|---|---|
Product: | Mesa | Reporter: | Arkadiusz Miskiewicz <arekm> |
Component: | Mesa core | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | galtgendo |
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | patch that sems to clean up unresolved symbols in libOSMesa (for mesa 8.1) |
Description
Arkadiusz Miskiewicz
2012-08-06 17:55:30 UTC
Created attachment 66184 [details] [review] patch that sems to clean up unresolved symbols in libOSMesa (for mesa 8.1) While I'm not 100% sure this patch is correct, it seems to clean up 'ldd -r' output for libOSmesa. As for dricore, I wonder why did it gain a version number in name and why isn't it simply compiled as a module (it would seem it more or less was before). You don't even want OSMesa linked against glapi at all, do you? If you link against glapi, can you use that OSMesa binary with, say, the nvidia proprietary drivers? (In reply to comment #2) > You don't even want OSMesa linked against glapi at all, do you? If you link > against glapi, can you use that OSMesa binary with, say, the nvidia proprietary > drivers? Not sure if I understand. Are you saying that OMMesa *shouldn't* be built with shared-glapi ? Cause correct me if I'm wrong, but aren't symbols like _glapi_tls_Context mesa specific ? Also, in regard of the earlier comment, why was dricore moved from /usr/lib/dri to /usr/lib ? Patch committed to master: http://cgit.freedesktop.org/mesa/mesa/commit/?id=1762ec28db4bfb85eeb6e61377839a3889f77216 Patch committed to 9.0: http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0&id=c8669c7ba7a01780d4cfd1cfc6ab8cc6f7fc2510 Fixed in 9.0. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.