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

[Emil Velikov]

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.

-Emil