[Mesa-dev] [PATCH 1/2 v3] configure: add visibility macro detectionto configure

Sedat Dilek sedat.dilek at gmail.com
Thu Feb 26 08:24:35 PST 2015

On Thu, Feb 26, 2015 at 4:56 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 26/02/15 15:26, Marc Dietrich wrote:
>> Am Donnerstag, 26. Februar 2015, 14:44:25 schrieb Emil Velikov:
>>> Hi Marc
>>> On 17/02/15 09:40, Marc Dietrich wrote:
>>>> This adds clang/gcc visibility macro detection to configure and
>>>> util/macros.h. This is can be used to conveniently add e.g. a "HIDDEN"
>>>> attribute to a function.
>>> I believe this should be OK to go in regardless of the status of patch
>>> 2. There are just a couple of trivial nitpicks.
>> as pointed out, not if there is a better solution. It would be nice if people
>> could test the alternative first.
> Can you point out which alternative you have in mind. I'm a bit lost in
> this thread.
> ...
>>>> @@ -245,17 +246,13 @@ if test "x$GCC" = xyes; then
>>>>                AC_MSG_RESULT([yes]),
>>>>                [CFLAGS="$save_CFLAGS -Wmissing-prototypes";
>>>>                 AC_MSG_RESULT([no])]);
>>>> +    CFLAGS=$save_CFLAGS
>>> I'm not sure we want/need this one ?
>> it restores the CFLAGS from the test above. In fact I just moved it from the
>> blow upwards. Maybe the diff could be shorter.
> Indeed it seems like it's slightly busted currently.
> Although the extra line does not seem to make it better though :-(
> Presently it adds to the final CFLAGS,
> -Werror=implicit-function-declaration
> -Werror=missing-prototypes
> or optionally
> -Wmissing-prototypes
> but with your change it won't add either one.
> ...
>> I always build with --enable-asm (or better without --disable-asm) and saw no
>> symbol clash. I guess because the required header is not included at the same
>> time. Is this possible at all (asm vs. c files)?
> Pretty sure you can - #include and #define are preprocessor commands.
> But as you noticed there was no clash, so we're ok.
>> Another interesting point is in which case we can build without shared-glapi.
>> I failed to build ES1 or ES2 alone, because it seem to always require glapi.
> Yes, to prevent even greater chaos or build permutations we've been
> mandating shared-glapi if more than one GL* api is selected. To solve
> this, just drop es{1,2} from the configure line.
>> This would mean that the dispatch table always begins with the glapi. Maybe I
>> confuse things, but in this case, just using
>>       extern void shared_dispatch_stub_0();
>> would solve all problems without the HIDDEN hacks.
> The so called hack is patch 2, afaict. Having a single generic
> definition of the attribute sounds like good patch regardless of that patch.
> I'm guessing scons and Android could use a
> -DHAVE_FUNC_ATTRIBUTE_VISIBILITY somewhere but that can be done as a
> follow-up.

Please CC me on patches for testing.
( I have updated my LLVM/Clang to v3.6.0rc4. )

- Sedat -

More information about the mesa-dev mailing list