Define PRIVATE and add it to all global symbols so we don't export assembly functions.

Define PRIVATE and add it to all global symbols so we don't export assembly functions.

BUG=50811
TEST=build a target w/ libvpx (like remoting_unittests) and observe no vp* symbols are global exported

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=97356

[scherkus (not reviewing), 2011-08-18 20:13:05]

FYI this is based off the previous bali release while tom works on prepping
cayuga

[jkoleszar, 2011-08-18 20:36:24]

LGTM

[Alpha Left Google, 2011-08-19 10:32:02]

On 2011/08/18 20:36:24, jkoleszar wrote:
> LGTM

Should this be upstreamed or already applied to cayuga?

[jkoleszar, 2011-08-19 12:54:25]

On 2011/08/19 10:32:02, Alpha wrote:
> On 2011/08/18 20:36:24, jkoleszar wrote:
> > LGTM
> 
> Should this be upstreamed or already applied to cayuga?

I think this is just a workaround for chromium at this point. When building a
DSO using the libvpx build system, we have a linker script that controls which
symbols are exported, so I don't think this is necessary in that case. I guess
it could be useful in the case where someone wants to take our static lib and
later link it into a DSO, so it might be worth including it upstream anyway. But
I don't think we can accept it until it doesn't rely on a patched yasm and/or we
have some way to detect whether yasm supported it so we could include it
conditionally.

[scherkus (not reviewing), 2011-08-19 19:54:16]

On 2011/08/19 12:54:25, jkoleszar wrote:
> On 2011/08/19 10:32:02, Alpha wrote:
> > On 2011/08/18 20:36:24, jkoleszar wrote:
> > > LGTM
> > 
> > Should this be upstreamed or already applied to cayuga?
> 
> I think this is just a workaround for chromium at this point. When building a
> DSO using the libvpx build system, we have a linker script that controls which
> symbols are exported, so I don't think this is necessary in that case. I guess
> it could be useful in the case where someone wants to take our static lib and
> later link it into a DSO, so it might be worth including it upstream anyway.
But
> I don't think we can accept it until it doesn't rely on a patched yasm and/or
we
> have some way to detect whether yasm supported it so we could include it
> conditionally.

I agree with jkoleszar. Unfortunately it's chromium specific. We can reduce the
chromium-ness is by upstreaming certain parts such as having a macro for
declaring globals which would let chromium just change the definition of said
macro as opposed to annotating each function individually.