[libdvdcss-devel] [PATCH] Re: libdvdcss.so does not distinguish internal from exposed API

[Fabian Greffrath]

Am 06.07.2012 18:50, schrieb Reimar Döffinger:
> Do you know if the configure check does the right thing on MinGW or
> cygwin? Those compilers might support both visibility and dllexport
> and they might have different semantics.

Well, according to [1] (which is an excellent read, btw, highly 
recommended!) things are a bit compilcated, but solvable:

It seems that both _EXPORTS or _IMPORTS are only #defined by MSVC, so 
if neither of them is #defined we are most probably using GCC and thus 
either building for _WIN32 (i.e. MinGW), __CYGWIN__ or Unix. Since 
both _WIN32 and __CYGWIN__ seem to understand the __declspec() 
semantics, it should be sufficient if none of them is #defined to test 
for (__GNUC__ >= 4) to be sure we are building on Unix with a 
sufficiently recent compiler.

At least this is what I read from the step-by-step guide.

So the attached implementation first checks if _WIN32 or __CYGWIN__ 
are #defined and then processes the whole Windows-centric block that 
was already there. If otherwise __GNUC__ is #defined and higher than 
4, then the symbol visibility attribute is applied. If neither _WIN32 
nor __CYGWIN__ nor __GNUC__ is #defined, then we fall back to the 
"extern" key word.

Both MinGW and Cygwin, which use GCC and thus have __GNUC__ #defined, 
enter the first block, because the symbol visibility feature is 
restricted to ELF and thus not suitable for Windows.

PS: This should allow for a somewhat simpler check in configure (at 
least without an additional #define), but I have not yet got so far.

  - Fabian

[1] http://gcc.gnu.org/wiki/Visibility
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvdcss_h.patch
Type: text/x-diff
Size: 714 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/libdvdcss-devel/attachments/20120710/22766e26/attachment.patch>