[VDPAU] Should we export these functions ? (Re: Exporting the flash workaround functions)

[Emil Velikov]

Hi José

Seems like I was a tad too pedantic over the wording used. Sorry for
the noise and thanks for the explanation :)

Cheers,
Emil

On 2 July 2014 16:13, José Hiram Soltren <jsoltren at nvidia.com> wrote:
> Hi Emil:
>
> Inline.
>
> On 07/01/2014 05:06 PM, Emil Velikov wrote:
>> José Hiram Soltren wrote:
>>> As for the DRI2 functions referenced in src/vdpau_wrapper.c: I don't see a
>>> reason for these to be non-static either. We implement our own mesa_dri2.c
>>> in libvdpau and only use this internally. I've CC'd Aaron who might be able
>>> to comment further. You are probably correct here as well.
>>
>> José,
>>
>> Thanks for the input. Yet, I do not see how one can define a function as
>> static and then use it in another source file. Perhaps I'm missing something ?
>
> As implemented in http://cgit.freedesktop.org/~aplattner/libvdpau/tree/ as of
> the tag 'libvdpau-0.8':
>
> src/mesa_dri2.h - VDPAU specific version of mesa_dri2.h, defines:
>
> _vdp_DRI2QueryExtension
> _vdp_DRI2QueryVersion
> _vdp_DRI2Connect
> _vdp_DRI2RemoveExtension
>
> src/mesa_dri2.c - implements these symbols.
>
> src/vdpau_wrapper.c - uses these symbols through '#include "mesa_dri2.h"'.
>
> As implemented, these four symbols in mesa_dri2.h must not be flagged with the
> 'static' keyword, since they are used in a different source file, as you
> correctly noted.
>
> In my reply, "non-static" should have read "exported by VDPAU in a .so". Since
> we go out of our way to implement VDPAU specific DRI functions for internal
> use, there is no good reason to export them.
>
> I agree with Aaron's proposal to use '-fvisibility=hidden'. This also agrees with:
>
> https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html
>
> I hope that clarifies any confusion.
>
> --José
>
>> Aaron Plattner wrote:
>>> Correct, those symbols should not be exported.  -fvisibility=hidden or
>>> equivalent options sound like the right way to go there on sufficiently
>>> new compilers, though there are also no prototypes for them in the
>>> public API headers so it should be obvious that they're not part of the
>>> exported ABI...
>>
>> That's exactly what I had planned Aaron. Check if the compiler supports
>> -fvisibility... and add a couple of symbols (PUBLIC & PRIVATE) in a private
>> header. Then explicitly annotate the symbols where required. Thanks for the
>> confirmation.
>>
>> Will try to find some time over the weekend.
>>
>> Thanks gents,
>> Emil
>>
>> P.S. Was not subscribed to the list, so I had to butcher your replies from the
>> ML archive. Just subscribed so I won't miss any replies :)
>>