[Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Emil Velikov]

On 19 October 2016 at 23:41, Jonathan Gray <jsg at jsg.id.au> wrote:
> On Wed, Oct 19, 2016 at 03:17:07PM +0100, Emil Velikov wrote:
>> On 19 October 2016 at 14:16, Jonathan Gray <jsg at jsg.id.au> wrote:
>> > On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote:
>> >> On 19 October 2016 at 01:05, Jonathan Gray <jsg at 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 <jsg at 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.engestrom at 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.engestrom at 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 <jsg at 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
>> Using a "plain" nm lists all the symbols - internal and exported. The
>> internal ones (which seems to be the one listed above) disappear as
>> you strip the binary (what I was checking here).
>>
>> To check only the exported ones you'd want either of the following
>> (admittedly the C is only to demangle C++ symbols).
>> $ nm -CD --defined-only foo.so
>> $ objdump -CT foo.so
>
> I compared them with a script that uses readelf to show they are exported.
> https://github.com/openbsd/src/blob/master/lib/check_sym
>
> They also show up with the flags you mentioned, and from what I understand
> they'd show up on all non x86/sparc archs on linux.
>
> $ arm-none-eabi-nm -CD --defined-only usr/lib/arm-linux-gnueabihf/libglapi.so.0.0.0 | fgrep shared_dispatch_stub | wc -l
>     1324
> $ objdump -CT usr/lib/arm-linux-gnueabihf/libglapi.so.0.0.0 | fgrep shared_dispatch_stub | wc -l
>     1324
Indeed looks like we only have the "hidden" notations for the ASM
generated dispatch - i.e. the x86 + sparc one.

Should be fixable, but it's too obvious where/how from a quick look.
Emil