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

[Emil Velikov]

On 19 October 2016 at 23:41, Jonathan Gray  wrote:
> On Wed, Oct 19, 2016 at 03:17:07PM +0100, Emil Velikov wrote:
>> On 19 October 2016 at 14:16, Jonathan Gray  wrote:
>> > On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote:
>> >> On 19 October 2016 at 01:05, Jonathan Gray  wrote:
>> >> > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
>> >> >> On 18 October 2016 at 00:58, Jonathan Gray  wrote:
>> >> >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
>> >> >> >> On 17 October 2016 at 16:39, Eric Engestrom 
>> >> >> >>  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 
>> >> >> >> >> >  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 
>> >> >> >> >> > >
>> >> >> >> >> > > 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 

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

[Jonathan Gray]

On Wed, Oct 19, 2016 at 03:17:07PM +0100, Emil Velikov wrote:
> On 19 October 2016 at 14:16, Jonathan Gray  wrote:
> > On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote:
> >> On 19 October 2016 at 01:05, Jonathan Gray  wrote:
> >> > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
> >> >> On 18 October 2016 at 00:58, Jonathan Gray  wrote:
> >> >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> >> >> >> On 17 October 2016 at 16:39, Eric Engestrom 
> >> >> >>  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 
> >> >> >> >> >  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 
> >> >> >> >> > >
> >> >> >> >> > > 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 
> > 

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

[Emil Velikov]

On 19 October 2016 at 14:16, Jonathan Gray  wrote:
> On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote:
>> On 19 October 2016 at 01:05, Jonathan Gray  wrote:
>> > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
>> >> On 18 October 2016 at 00:58, Jonathan Gray  wrote:
>> >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
>> >> >> On 17 October 2016 at 16:39, Eric Engestrom 
>> >> >>  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 
>> >> >> >> >  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 
>> >> >> >> > >
>> >> >> >> > > 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 

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

[Jonathan Gray]

On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote:
> On 19 October 2016 at 01:05, Jonathan Gray  wrote:
> > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
> >> On 18 October 2016 at 00:58, Jonathan Gray  wrote:
> >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> >> >> On 17 October 2016 at 16:39, Eric Engestrom  
> >> >> 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 
> >> >> >> >  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 
> >> >> >> > >
> >> >> >> > > 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

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

[Emil Velikov]

On 19 October 2016 at 01:05, Jonathan Gray  wrote:
> On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
>> On 18 October 2016 at 00:58, Jonathan Gray  wrote:
>> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
>> >> On 17 October 2016 at 16:39, Eric Engestrom  
>> >> 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 
>> >> >> >  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 
>> >> >> > >
>> >> >> > > 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jonathan Gray]

On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
> On 18 October 2016 at 00:58, Jonathan Gray  wrote:
> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> >> On 17 October 2016 at 16:39, Eric Engestrom  
> >> 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 
> >> >> >  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 
> >> >> > >
> >> >> > > 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.

> 
> > I'd prefer the diff I mailed for OpenBSD for if the major version
> > should crank for some reason.
> Let's worry about that if/when it happens ?

sure

> 
> Emil
> /me lands the rest of the patches

thankS
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 18 October 2016 at 00:58, Jonathan Gray  wrote:
> On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
>> On 17 October 2016 at 16:39, Eric Engestrom  
>> 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  
>> >> > 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 
>> >> > >
>> >> > > 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.

> I'd prefer the diff I mailed for OpenBSD for if the major version
> should crank for some reason.
Let's worry about that if/when it happens ?

Emil
/me lands the rest of the patches
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jonathan Gray]

On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> On 17 October 2016 at 16:39, Eric Engestrom  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  
> >> > 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 
> >> > >
> >> > > 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.

I'd prefer the diff I mailed for OpenBSD for if the major version
should crank for some reason.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 17 October 2016 at 16:39, Eric Engestrom  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  
>> > 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 
>> > >
>> > > 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 ?

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eric Engestrom]

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  
> > 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 
> > >
> > > 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:

8<
@@ -2808,10 +2808,8 @@ dri2_load(_EGLDriver *drv)
const char *libname = "libglapi.0.dylib";
 #elif defined(__CYGWIN__)
const char *libname = "cygglapi-0.dll";
-#elif defined(__linux__)
+#else
const char *libname = "libglapi.so.0";
-#else
-#error Unknown glapi provider for this platform
 #endif
void *handle;
 
>8

> 
> > 
> > > Fixes: 7a9c92d071d010066349 ("egl/dri2: non-shared glapi cleanups")
> > > Reviewed-by: Eric Engestrom 
> > >
> > > Side note, I don't understand why we hardcode the version everywhere
> > > (except Android). I can see it's been like that since that code was
> > > added nearly 6 years ago (218381d9), but I couldn't find an explanation
> > > in the logs, or any mention of it in the thread I found [1].
> > > Emil, do you know?
> > >
> > The ABI must be stable. Since a) we (and linux distros in general)
> > have the greater flexibility to "mix and match" components and b)
> > glapi is/was used by xserver as well, the initial goal was that the
> > ABI should not break, ever. See some the src/mapi changes by Brian
> > Paul, which rework the nop calls due to different calling convention
> > and stack corruption on Windows and the follow up fix to keep those
> > Windows only and stable for everyone else
> > be71bbfaa2ad201b570b56847a13328fc359d0ee.

Right, makes sense. Thanks for spending the time to educate me :P

> > 
> > Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jonathan Gray]

On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
> On 17 October 2016 at 10:53, Eric Engestrom  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 
> >
> > 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 ?

> 
> > Fixes: 7a9c92d071d010066349 ("egl/dri2: non-shared glapi cleanups")
> > Reviewed-by: Eric Engestrom 
> >
> > Side note, I don't understand why we hardcode the version everywhere
> > (except Android). I can see it's been like that since that code was
> > added nearly 6 years ago (218381d9), but I couldn't find an explanation
> > in the logs, or any mention of it in the thread I found [1].
> > Emil, do you know?
> >
> The ABI must be stable. Since a) we (and linux distros in general)
> have the greater flexibility to "mix and match" components and b)
> glapi is/was used by xserver as well, the initial goal was that the
> ABI should not break, ever. See some the src/mapi changes by Brian
> Paul, which rework the nop calls due to different calling convention
> and stack corruption on Windows and the follow up fix to keep those
> Windows only and stable for everyone else
> be71bbfaa2ad201b570b56847a13328fc359d0ee.
> 
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 17 October 2016 at 10:53, Eric Engestrom  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 
>
> 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 ;-)

> Fixes: 7a9c92d071d010066349 ("egl/dri2: non-shared glapi cleanups")
> Reviewed-by: Eric Engestrom 
>
> Side note, I don't understand why we hardcode the version everywhere
> (except Android). I can see it's been like that since that code was
> added nearly 6 years ago (218381d9), but I couldn't find an explanation
> in the logs, or any mention of it in the thread I found [1].
> Emil, do you know?
>
The ABI must be stable. Since a) we (and linux distros in general)
have the greater flexibility to "mix and match" components and b)
glapi is/was used by xserver as well, the initial goal was that the
ABI should not break, ever. See some the src/mapi changes by Brian
Paul, which rework the nop calls due to different calling convention
and stack corruption on Windows and the follow up fix to keep those
Windows only and stable for everyone else
be71bbfaa2ad201b570b56847a13328fc359d0ee.

Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eric Engestrom]

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 

LGTM, and I guess the other *BSD will want the same since 7a9c92d0 broke
them too.

Fixes: 7a9c92d071d010066349 ("egl/dri2: non-shared glapi cleanups")
Reviewed-by: Eric Engestrom 

Side note, I don't understand why we hardcode the version everywhere
(except Android). I can see it's been like that since that code was
added nearly 6 years ago (218381d9), but I couldn't find an explanation
in the logs, or any mention of it in the thread I found [1].
Emil, do you know?

[1] https://lists.freedesktop.org/archives/mesa-dev/2010-December/004476.html

> ---
>  src/egl/drivers/dri2/egl_dri2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 8785e31..9655a49 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -2802,7 +2802,7 @@ static EGLBoolean
>  dri2_load(_EGLDriver *drv)
>  {
> struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
> -#ifdef HAVE_ANDROID_PLATFORM
> +#if defined(HAVE_ANDROID_PLATFORM) || defined(__OpenBSD__)
> const char *libname = "libglapi.so";
>  #elif defined(__APPLE__)
> const char *libname = "libglapi.0.dylib";
> -- 
> 2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jonathan Gray]

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 
---
 src/egl/drivers/dri2/egl_dri2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 8785e31..9655a49 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2802,7 +2802,7 @@ static EGLBoolean
 dri2_load(_EGLDriver *drv)
 {
struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
-#ifdef HAVE_ANDROID_PLATFORM
+#if defined(HAVE_ANDROID_PLATFORM) || defined(__OpenBSD__)
const char *libname = "libglapi.so";
 #elif defined(__APPLE__)
const char *libname = "libglapi.0.dylib";
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev