Re: [Mesa-dev] Can --enable-shared-glapi die?
On Tue, 2012-07-24 at 10:45 -0700, Ian Romanick wrote: On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? Thanks to all for the refresher. Off-list someone raised another issue to me that seems like a deal breaker. If an application links with a libGL that uses libglapi it appears that the application gets implicitly linked with libglapi (as shown by objdump -x | grep -i need). This will cause the application to fail if a non-glapi libGL (i.e., any of the closed-source drivers) is later installed. The problem seems to be that symbols like glBegin are in libglapi. Is this fixable? I think the usual cause for this is linking with libtool. By default, libtool will read the libGL.la file associated with your libGL.so, and add all of the dependency libraries listed in the .la file to the link command line, even if the operating system does not require them to be linked in. (There are some options that some versions of ld have that will cause ld to ignore these libraries and not *actually* link them in; some newer distributions are starting to use these options) The easy workaround is simply to delete the libGL.la file after installation, to force libtool to link *only* to libGL.so. -- Calvin Walton calvin.wal...@kepstin.ca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On 24/07/2012 02:08, Matt Turner wrote: On Mon, Jul 23, 2012 at 3:15 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? The --enable-shared-glapi option allows programs to use both libGL.so and libGLESv2.so without zillions of conflicting linker symbols. IIRC it basically extracts the API dispatch stuff into libglapi.so and makes both libraries depend on a single copy. I'm failing at email archaeology, but I know we've talked about this before. I believe Chia-I said he thought it would be a good idea to make it the default, but essentially left the option as a chicken bit, in case it didn't work in all situations. It looks like Matt Turner, Jon Turney, and Homer Hsing also approved of the change. Somebody had a patch but I can't find it now. The only trouble I know about is that if your libglapi gets out of sync with your libGL/libGLES, all hell breaks loose: glCompileShader gets routed to glLinkProgram and so on. Apps fail in spectacular ways. But as long as you keep them in sync (and it's not hard), then it works fine. I'm all for making shared-glapi mandatory. People who care about GLES will want it (and thus distros would want it), there's no real downside, and reducing the number of configurations would be great. Yeah, I think I had a patch to make this mandatory. I'm also not remembering why it wasn't committed. It seems like there was some configuration (xlib-glx, osmesa, etc) that didn't work with shared-glapi. Committed adefee50d954151f76150af80207081ae3c247d9 and reverted 027ce0c493a85c863df88b43f61aea34bcd4cd58 https://bugs.freedesktop.org/show_bug.cgi?id=45660 describes a part of the breakage and it's fix. Since it doesn't actually seem to be that well tested, perhaps making it the default for a while before removing the option might be a good idea? One could wish for a clearer diagnostic than all your GL programs getting hilariously broken when using the wrong shared glapi, although I'm not sure what sort of version check we could do. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? Thanks to all for the refresher. Off-list someone raised another issue to me that seems like a deal breaker. If an application links with a libGL that uses libglapi it appears that the application gets implicitly linked with libglapi (as shown by objdump -x | grep -i need). This will cause the application to fail if a non-glapi libGL (i.e., any of the closed-source drivers) is later installed. The problem seems to be that symbols like glBegin are in libglapi. Is this fixable? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On 07/24/2012 05:49 AM, Jon TURNEY wrote: Committed adefee50d954151f76150af80207081ae3c247d9 and reverted 027ce0c493a85c863df88b43f61aea34bcd4cd58 https://bugs.freedesktop.org/show_bug.cgi?id=45660 describes a part of the breakage and it's fix. Since it doesn't actually seem to be that well tested, perhaps making it the default for a while before removing the option might be a good idea? Sounds like a good idea. One could wish for a clearer diagnostic than all your GL programs getting hilariously broken when using the wrong shared glapi, although I'm not sure what sort of version check we could do. Ian and I had talked about putting some sort of canary in the dispatch tables, and having it check on startup. If the canary is wrong, make it die with a printf. I haven't looked into how to do that, though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On 7/24/12 1:45 PM, Ian Romanick wrote: On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? Thanks to all for the refresher. Off-list someone raised another issue to me that seems like a deal breaker. If an application links with a libGL that uses libglapi it appears that the application gets implicitly linked with libglapi (as shown by objdump -x | grep -i need). This part is actually dependent on whether the app is built with --copy-dt-needed-entries. Historically that's been the default, but most modern distros have switched to --no-copy-etc, in which case the app will _not_ get a DT_NEEDED on libglapi just for linking against libGL. This is good; apps shouldn't be made accidentally fragile based on implementation details of the libraries they link against. But it does require a modestly recent linker with that option, or with it under the old spelling of --no-add-needed. This will cause the application to fail if a non-glapi libGL (i.e., any of the closed-source drivers) is later installed. The problem seems to be that symbols like glBegin are in libglapi. That doesn't jive with what my linker says, at least looking at an F16 machine: atropine:~% nm -aD --defined /usr/lib/libglapi.so 0002f060 A __bss_start 0002f060 A _edata 0002fcf4 A _end 000178a8 T _fini 0002fcf0 B _glapi_Context 0002f05c D _glapi_Dispatch 00016d60 T _glapi_add_dispatch 00016cd0 T _glapi_check_multithread 00017420 T _glapi_get_context 00017600 T _glapi_get_dispatch 00016d50 T _glapi_get_dispatch_table_size 00016f80 T _glapi_get_proc_address 00017000 T _glapi_get_proc_name 00016f00 T _glapi_get_proc_offset 00017030 T _glapi_noop_enable_warnings 00016cf0 T _glapi_set_context 00016d20 T _glapi_set_dispatch 00017040 T _glapi_set_warning_func 00017010 T _glthread_GetID 4ef8 T _init That's all libGL-to-dispatch bridging, it's not app API. There's no reason the app would need a DT_NEEDED against libglapi. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Can --enable-shared-glapi die?
Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? The --enable-shared-glapi option allows programs to use both libGL.so and libGLESv2.so without zillions of conflicting linker symbols. IIRC it basically extracts the API dispatch stuff into libglapi.so and makes both libraries depend on a single copy. I'm failing at email archaeology, but I know we've talked about this before. I believe Chia-I said he thought it would be a good idea to make it the default, but essentially left the option as a chicken bit, in case it didn't work in all situations. It looks like Matt Turner, Jon Turney, and Homer Hsing also approved of the change. Somebody had a patch but I can't find it now. The only trouble I know about is that if your libglapi gets out of sync with your libGL/libGLES, all hell breaks loose: glCompileShader gets routed to glLinkProgram and so on. Apps fail in spectacular ways. But as long as you keep them in sync (and it's not hard), then it works fine. I'm all for making shared-glapi mandatory. People who care about GLES will want it (and thus distros would want it), there's no real downside, and reducing the number of configurations would be great. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On Mon, Jul 23, 2012 at 3:15 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? The --enable-shared-glapi option allows programs to use both libGL.so and libGLESv2.so without zillions of conflicting linker symbols. IIRC it basically extracts the API dispatch stuff into libglapi.so and makes both libraries depend on a single copy. I'm failing at email archaeology, but I know we've talked about this before. I believe Chia-I said he thought it would be a good idea to make it the default, but essentially left the option as a chicken bit, in case it didn't work in all situations. It looks like Matt Turner, Jon Turney, and Homer Hsing also approved of the change. Somebody had a patch but I can't find it now. The only trouble I know about is that if your libglapi gets out of sync with your libGL/libGLES, all hell breaks loose: glCompileShader gets routed to glLinkProgram and so on. Apps fail in spectacular ways. But as long as you keep them in sync (and it's not hard), then it works fine. I'm all for making shared-glapi mandatory. People who care about GLES will want it (and thus distros would want it), there's no real downside, and reducing the number of configurations would be great. Yeah, I think I had a patch to make this mandatory. I'm also not remembering why it wasn't committed. It seems like there was some configuration (xlib-glx, osmesa, etc) that didn't work with shared-glapi. I'll take a look and try to get this sorted out. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On Mon, Jul 23, 2012 at 9:08 PM, Matt Turner matts...@gmail.com wrote: On Mon, Jul 23, 2012 at 3:15 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? The --enable-shared-glapi option allows programs to use both libGL.so and libGLESv2.so without zillions of conflicting linker symbols. IIRC it basically extracts the API dispatch stuff into libglapi.so and makes both libraries depend on a single copy. I'm failing at email archaeology, but I know we've talked about this before. I believe Chia-I said he thought it would be a good idea to make it the default, but essentially left the option as a chicken bit, in case it didn't work in all situations. It looks like Matt Turner, Jon Turney, and Homer Hsing also approved of the change. Somebody had a patch but I can't find it now. The only trouble I know about is that if your libglapi gets out of sync with your libGL/libGLES, all hell breaks loose: glCompileShader gets routed to glLinkProgram and so on. Apps fail in spectacular ways. But as long as you keep them in sync (and it's not hard), then it works fine. I'm all for making shared-glapi mandatory. People who care about GLES will want it (and thus distros would want it), there's no real downside, and reducing the number of configurations would be great. Yeah, I think I had a patch to make this mandatory. I'm also not remembering why it wasn't committed. It seems like there was some configuration (xlib-glx, osmesa, etc) that didn't work with shared-glapi. Yeah, I'd like to see it happen too, but I think osmesa doesn't work with shared-glapi: https://bugs.freedesktop.org/show_bug.cgi?id=47824 Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
