[Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection

Sedat Dilek sedat.dilek at gmail.com
Sun Mar 1 14:38:15 PST 2015


On Sun, Mar 1, 2015 at 11:31 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 01/03/15 21:05, Alan Coopersmith wrote:
>> On 03/ 1/15 10:57 AM, Emil Velikov wrote:
>>> On 01/03/15 18:30, Matt Turner wrote:
>>>> On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich <marvin24 at gmx.de> wrote:
>>>>> This patch simplifies the visibility compiler flag detection in
>>>>> configure and
>>>>> makes it more generic to also support compilers other than gcc.
>>>>
>>>> This simplification relies on the assumption that compilers support
>>>> -fvisibility=... if and only if they support
>>>> attribute(visibility("...")).
>>>>
>>> Hmm you're correct. I've naively assumed they both go hand in hand.
>>
>> The latest Solaris Studio compilers support attribute(visibility), but
>> not -fvisibility.  The absolute latest (12.4, released a few months back)
>> also support the clang has_attribute() extension for checking what's
>> supported (which is one of the reasons it's used in the X11/Xfuncproto.h
>> header in xproto 7.0.27 & later).
>>
> Ouch... so I was quite naive indeed.
>
> So here are some interesting bits:
>
>  - HAVE_FUNC_ATTRIBUTE_VISIBILITY is likely to be undefined (0) with
> Solaris Studio compilers, as the m4 macro checks for
>
> __attribute__((visibility("default")));
> __attribute__((visibility("hidden")));
> __attribute__((visibility("internal")));
> __attribute__((visibility("protected")));
>
> As the last one does not appear in the 12.4 C User's Guide (linked
> below) the compiler will likely error/warn.
>
> Perhaps we can nuke the latter two, as they are unused presently, and
> add them back when needed ?
>
>  - Considering the lack of -fvisibility, what is the normal visibility
> "level" - hidden or default ? If the latter this means that every
> library/module built exports a ton of internal symbols.
>

>From [1] for gcc:

"Despite the nomenclature, ‘default’ always means public; i.e.,
available to be linked against from outside the shared object.
‘protected’ and ‘internal’ are pretty useless in real-world usage so
the only other commonly used option is ‘hidden’. The default if
-fvisibility isn't specified is ‘default’, i.e., make every symbol
public—this causes the same behavior as previous versions of GCC. "

- Sedat -

[1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html ->
"-fvisibility=[default|internal|hidden|protected]"

>  - Using the __has_attribute macro looks great, although I would suspect
> that it will take a while for GCC and others to adopt(?).
>
> Thanks for the insightful input Alan.
>
> -Emil
>
>> https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html
>> https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html
>> http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e
>>
>>
>


More information about the mesa-dev mailing list