[Mesa-dev] [PATCH 2/2] mesa/glsl: rename preprocess to glcpp_preprocess

Dave Airlie airlied at gmail.com
Thu Sep 13 23:44:09 PDT 2012


On Fri, Sep 14, 2012 at 4:36 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 09/13/2012 05:13 PM, Dave Airlie wrote:
>> From: Dave Airlie <airlied at redhat.com>
>>
>> This symbol with dricore escapes into the namespace, its too generic,
>> we should prefix it with something just to be nice.
>>
>> Should be applied to stable + 9.0
>>
>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>
> Forgive me for not understanding how linkers work, but...this symbol
> should -not- be exposed at all.  It's completely internal and nobody
> except the current callers should ever call it.  If it's getting exposed
> that's broken and we need to fix that.  I hate to think what else is
> getting exposed.
>
> As I understand it, all of our visibility flags stopped taking effect at
> some point during the automake conversion.  We need to figure out why
> and how to fix it...IMHO we can't release without fixing that.
>
> Is it not possible?

Not with libdricore, since we have no defined API between it and the drivers.

If we want visibility to work we need to either drop libdricore, or
start to markup the visible APIs between it and the drivers. ajax
suggested a crazy script to build it all, get the list of apis needed
by the drivers, rebuild with those exposed. I'm not sure how feasible
that is.

Since neither of these seem like a simple plan, I'd at least try to
limit the damage in the 9.0 timeframe which is what these two patches
do. yylex is definite problem preprocess was the most generic one I
saw after that.

Dave.


More information about the mesa-dev mailing list