Add PRIVATE flags to global symbols....

Add PRIVATE flags to global symbols.
This change adds the 'private_extern' flags (on Mac) or the 'hidden' flags (on Linux) to the all global symbols in libjpeg-turbo as suggested in <http://codereview.chromium.org/6332003/>;.

BUG=none
TEST=build Chromium on Mac without any changes to the 'framework.order' file.

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

[Mark Mentovai, 2011-02-04 12:55:13]

LGTM

[fta, 2011-02-08 18:49:43]

On 2011/02/04 12:55:13, Mark Mentovai wrote:
> LGTM

seems to be causing this regression: http://paste.ubuntu.com/564553/

[Hironori Bono, 2011-02-09 02:09:32]

Greetings Fabien,

Sorry for your inconvenience.
If I recall correctly, your builder uses an older GYP than r872.
Unfortunately, building libjpeg-turbo requires GYP r873. Can you merge
r873 to your GYP copy
<http://code.google.com/p/gyp/source/detail?r=873>?

Regards,

Hironori Bono
E-mail: hbono@google.com

On Wed, Feb 9, 2011 at 3:49 AM,  <fta@sofaraway.org> wrote:
> On 2011/02/04 12:55:13, Mark Mentovai wrote:
>>
>> LGTM
>
> seems to be causing this regression: http://paste.ubuntu.com/564553/
>
> http://codereview.chromium.org/6246098/
>

[fta, 2011-02-09 06:25:44]

hi,

this build (obviously trunk) is tracking the gyp requested in DEPS, so
it is r874. But it is a disable_sse2=1 build.

/Fabien

-----Original Message-----
From: Hironori Bono (坊野 博典) <hbono@chromium.org>
To: hbono@chromium.org, mark@chromium.org, fta@sofaraway.org,
chromium-reviews@chromium.org
Subject: Re: Add PRIVATE flags to global symbols.... (issue6246098)
Date: Wed, 9 Feb 2011 11:09:23 +0900

Greetings Fabien,

Sorry for your inconvenience.
If I recall correctly, your builder uses an older GYP than r872.
Unfortunately, building libjpeg-turbo requires GYP r873. Can you merge
r873 to your GYP copy
<http://code.google.com/p/gyp/source/detail?r=873>?

Regards,

Hironori Bono
E-mail: hbono@google.com

On Wed, Feb 9, 2011 at 3:49 AM,  <fta@sofaraway.org> wrote:
> On 2011/02/04 12:55:13, Mark Mentovai wrote:
>>
>> LGTM
>
> seems to be causing this regression: http://paste.ubuntu.com/564553/
>
> http://codereview.chromium.org/6246098/
>

[Hironori Bono, 2011-02-09 06:32:39]

Greetings Fabien,

Thank you for your update.
Since we can switch back to libjpeg-6b when we add 'use_libjpeg_turbo'
to 0, is it possible to add "'use_libjpeg_turbo': 0" to your
"~/.gyp/include.gypi" until I can figure out why it fails on your
builder? Also, is it possible to send me the
'src/third_party/libjpeg_turbo/libjpeg.target.mk' so I can read the
output Makefile?

Regards,

Hironori Bono
E-mail: hbono@chromium.org

On Wed, Feb 9, 2011 at 3:25 PM, Fabien Tassin <fta@sofaraway.org> wrote:
> hi,
>
> this build (obviously trunk) is tracking the gyp requested in DEPS, so
> it is r874. But it is a disable_sse2=1 build.
>
> /Fabien
>
> -----Original Message-----
> From: Hironori Bono (坊野 博典) <hbono@chromium.org>
> To: hbono@chromium.org, mark@chromium.org, fta@sofaraway.org,
> chromium-reviews@chromium.org
> Subject: Re: Add PRIVATE flags to global symbols.... (issue6246098)
> Date: Wed, 9 Feb 2011 11:09:23 +0900
>
> Greetings Fabien,
>
> Sorry for your inconvenience.
> If I recall correctly, your builder uses an older GYP than r872.
> Unfortunately, building libjpeg-turbo requires GYP r873. Can you merge
> r873 to your GYP copy
> <http://code.google.com/p/gyp/source/detail?r=873>?
>
> Regards,
>
> Hironori Bono
> E-mail: hbono@google.com
>
> On Wed, Feb 9, 2011 at 3:49 AM,  <fta@sofaraway.org> wrote:
>> On 2011/02/04 12:55:13, Mark Mentovai wrote:
>>>
>>> LGTM
>>
>> seems to be causing this regression: http://paste.ubuntu.com/564553/
>>
>> http://codereview.chromium.org/6246098/
>>
>
>
>
>

[msarett, 2016-05-04 17:37:08]

msarett@google.com changed reviewers:
+ msarett@google.com

[msarett, 2016-05-04 17:37:09]

Hi Mark,

I've just updated libjpeg_turbo to 1.4.90.
https://chromium.googlesource.com/chromium/deps/libjpeg_turbo

I think I'll need to reapply this change before rolling DEPS.  Can you help me
understand why it was necessary (and if it's still necessary)?  Is this
something we should consider upstreaming to libjpeg-turbo?

I realize this was a long time ago, so feel free to let me know if it's too far
back to remember :).

Best,
Matt

[Mark Mentovai, 2016-05-04 18:28:24]

LGTM

If you don’t do this, we wind up exposing all of libjpeg_turbo’s symbols from
our main module. We don’t need to do that, since we’re not providing
libjpeg_turbo to anyone but ourselves. It bloats the symbol table and makes
system crash reports look stupid, and everyone starts blaming all of their
crashes on libjpeg_turbo.

The verify_order step ensures that some generic-sounding symbol name (“main”) is
the highest-addressed exported symbol in the module, so that when a crash report
shows up with an offset way out into the module somewhere and the system’s
symbolizer tries to associate a function name with it, it picks “main +
huge_offset” instead of “random_symbol + smaller_offset”. That’s what causes
people to blame their crashes on the wrong thing. We have an “order” file that
lists all of the symbols that we want to export, and puts “main” last, so that’s
what the symbol table will look like, and we won’t have this problem of people
trying to blame weird crashes on unrelated code.