On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote: > On 19 October 2016 at 01:05, Jonathan Gray <j...@jsg.id.au> wrote: > > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote: > >> On 18 October 2016 at 00:58, Jonathan Gray <j...@jsg.id.au> wrote: > >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote: > >> >> On 17 October 2016 at 16:39, Eric Engestrom <eric.engest...@imgtec.com> > >> >> wrote: > >> >> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote: > >> >> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote: > >> >> >> > On 17 October 2016 at 10:53, Eric Engestrom > >> >> >> > <eric.engest...@imgtec.com> wrote: > >> >> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote: > >> >> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find > >> >> >> > >> the highest major/minor version and open it in this case. > >> >> >> > >> > >> >> >> > >> Avoids '#error Unknown glapi provider for this platform' at > >> >> >> > >> build time. > >> >> >> > >> > >> >> >> > >> Signed-off-by: Jonathan Gray <j...@jsg.id.au> > >> >> >> > > > >> >> >> > > LGTM, and I guess the other *BSD will want the same since > >> >> >> > > 7a9c92d0 broke > >> >> >> > > them too. > >> >> >> > > > >> >> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump > >> >> >> > the > >> >> >> > major when the ABI breaks due to 'internal' changes - think of > >> >> >> > off_t/time_t on 32 vs 64bit systems and alike. > >> >> >> > > >> >> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in > >> >> >> > comes to ABI, I believe. Don't quote me on that one ;-) > >> >> >> > >> >> >> OpenBSD tends to favour simplified interfaces over backwards > >> >> >> compatiblity > >> >> >> and is more like a research system in that respect. As the kernel > >> >> >> and userland are one source tree ioctl compat largely doesn't exist. > >> >> >> System calls get deprecated and removed over the course of a few > >> >> >> releases. > >> >> >> So we didn't go through the pain of duplicated systems calls for > >> >> >> off_t > >> >> >> as mentioned, and don't go in for symbol versioning. Just > >> >> >> major.minor > >> >> >> library versioning, which is roughly symbol removals, major crank, > >> >> >> symbol additions minor crank. > >> >> >> > >> >> >> I believe FreeBSD tends to go in for backwards compatibility more > >> >> >> but am not familiar with the details. They also have a different > >> >> >> ld.so. > >> >> >> > >> >> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all > >> >> >> the other various unices instead of the #error ? > >> >> > > >> >> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be > >> >> > a better, > >> >> > to avoid the potentially huge list of every *BSD and other Unix: > >> >> > > >> >> Fwiw I've intentionally added the hunk since I was a bit lazy to check > >> >> if the BSD(s?)/Solaris/others have bumped the major locally. Having a > >> >> closer look that's not the case, so indeed we can add revert to > >> >> libglapi.so.0 in the else statement. > >> >> > >> >> Jonathan, how about we with the above instead ? > >> > > >> > At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2. > >> > New versions of Mesa add new shared_dispatch_stub_* symbols, > >> > which the minor would crank for. > >> > > >> Don't think we [intentionally] added any symbols for a long while. > > > > Comparing 11.2.2 libglapi and the latest Mesa I see: > > > > Dynamic export changes: > > added: > > shared_dispatch_stub_1323 > > shared_dispatch_stub_1324 > > shared_dispatch_stub_1325 > > shared_dispatch_stub_1326 > > shared_dispatch_stub_1327 > > shared_dispatch_stub_1328 > > shared_dispatch_stub_1329 > > > > Perhaps this is unique to the non-tls dispatch case though. > > > Seems like it. Either way, the symbols are exported unintentionally, > since they are not part of the glapi API and are not used outside of > libglapi.so. > > Any patch(es) to hide them will be gladly appreciated.
It seems only the arch specific glapi asm stubs get it right? I manually extracted the libglapi from debian's Mesa 12.0.3 for amd64 and armhf and the shared_dispatch_stub symbols show up with debian's armhf library (but not amd64). http://ftp.au.debian.org/debian/pool/main/m/mesa/libglapi-mesa_12.0.3-1_armhf.deb $ nm usr/lib/arm-linux-gnueabihf/libglapi.so.0.0.0 | fgrep ' T shared_dispatch_stub' | wc -l 1324 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
