Allows translator_glsl to be built as a shared library

Allows translator_glsl to be built as a shared library

http://codereview.chromium.org/8222028/ uses translator_glsl from multiple
chromium components. Unfortunately, it causes problems at least on linux: The
translator leaks weak symbols because of stl template instantiation, which have
"vague" linkage. Because these symbol leak, the code jumps arbitrarily across
the 2 versions of the static lib, that use different globals, leading to
incorrect behavior.
The solution to that is to be able to have translator_glsl be a shared library
itself, so that it's not duplicated.

BUG=None
TEST=compile chrome with component=shared_library in GYP_DEFINES

[apatrick1, 2011-10-20 21:34:46]

Looks okay. Just curious about the comment inline.

You need to update src/common/version.h with the subversion revision you think
the patch will get before checking in.

Are you a committer?

http://codereview.appspot.com/5305052/diff/1/src/build_angle.gyp
File src/build_angle.gyp (right):

http://codereview.appspot.com/5305052/diff/1/src/build_angle.gyp#newcode131
src/build_angle.gyp:131: 'target_name': 'translator_hlsl',
Would doing the same to translator_hlsl break anything in the shared library
build of chrome? Or is it just that you don't need it as a shared library?

[piman, 2011-10-20 22:03:55]

On 2011/10/20 21:34:46, apatrick1 wrote:
> Looks okay. Just curious about the comment inline.
> 
> You need to update src/common/version.h with the subversion revision you think
> the patch will get before checking in.

Err, ok... that's "interesting". I'll do that.

> 
> Are you a committer?

Nope

> 
> http://codereview.appspot.com/5305052/diff/1/src/build_angle.gyp
> File src/build_angle.gyp (right):
> 
> http://codereview.appspot.com/5305052/diff/1/src/build_angle.gyp#newcode131
> src/build_angle.gyp:131: 'target_name': 'translator_hlsl',
> Would doing the same to translator_hlsl break anything in the shared library
> build of chrome? Or is it just that you don't need it as a shared library?

We don't need it as a shared library, because we don't link to it from chrome.
AFAICT it's only used by the GLESv2 lib, which whitelists the symbols (with the
DEF file), so the problem wouldn't come up.
Actually we can't even link translator_hlsl and translator_glsl together into
the same executable since they define the same symbols.

[piman, 2011-10-20 22:05:54]

On 2011/10/20 22:03:55, piman wrote:
> On 2011/10/20 21:34:46, apatrick1 wrote:
> > Looks okay. Just curious about the comment inline.
> > 
> > You need to update src/common/version.h with the subversion revision you
think
> > the patch will get before checking in.
> 
> Err, ok... that's "interesting". I'll do that.

Done.

[apatrick1, 2011-10-20 22:06:03]

Okay I'll land it then and I'll do the interesting thing with the revision
number.

[piman, 2011-10-20 22:22:00]

On Thu, Oct 20, 2011 at 3:06 PM, <apatrick@chromium.org> wrote:

> Okay I'll land it then and I'll do the interesting thing with the
> revision number.
>

Thanks :)

Antoine


>
>
http://codereview.appspot.com/**5305052/<http://codereview.appspot.com/5305052/>
>

[apatrick1, 2011-10-20 22:24:54]

Hmm. Building ANGLE from the gyp generated VS projects I get errors like:

5>------ Rebuild All started: Project: essl_to_hlsl, Configuration: Debug Win32
------
5>Deleting intermediate and output files for project 'essl_to_hlsl',
configuration 'Debug|Win32'
5>Compiling...
5>debug.cpp
5>translator.cpp
5>Generating Code...
5>Compiling manifest to resources...
5>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
5>Copyright (C) Microsoft Corporation.  All rights reserved.
5>Linking...
5>translator.obj : error LNK2019: unresolved external symbol
__imp__ShInitBuiltInResources referenced in function "void __cdecl
GenerateResources(struct ShBuiltInResources *)"
(?GenerateResources@@YAXPAUShBuiltInResources@@@Z)
5>translator.obj : error LNK2019: unresolved external symbol __imp__ShFinalize
referenced in function _main
5>translator.obj : error LNK2019: unresolved external symbol __imp__ShDestruct
referenced in function _main
5>translator.obj : error LNK2019: unresolved external symbol
__imp__ShGetObjectCode referenced in function _main
5>translator.obj : error LNK2019: unresolved external symbol __imp__ShGetInfoLog
referenced in function _main
5>translator.obj : error LNK2019: unresolved external symbol __imp__ShGetInfo
referenced in function _main
5>translator.obj : error LNK2019: unresolved external symbol
__imp__ShConstructCompiler referenced in function _main
5>translator.obj : error LNK2019: unresolved external symbol __imp__ShInitialize
referenced in function _main
5>translator.obj : error LNK2019: unresolved external symbol __imp__ShCompile
referenced in function "bool __cdecl CompileFile(char *,void *,int)"
(?CompileFile@@YA_NPADPAXH@Z)
5>translator.obj : error LNK2019: unresolved external symbol
__imp__ShGetActiveUniform referenced in function "void __cdecl
PrintActiveVariables(void *,enum ShShaderInfo,bool)"
(?PrintActiveVariables@@YAXPAXW4ShShaderInfo@@_N@Z)
5>translator.obj : error LNK2019: unresolved external symbol
__imp__ShGetActiveAttrib referenced in function "void __cdecl
PrintActiveVariables(void *,enum ShShaderInfo,bool)"
(?PrintActiveVariables@@YAXPAXW4ShShaderInfo@@_N@Z)

I clobbered first. I had this in my include.gypi:

{
  'variables': {
    'component': 'shared_library',
    'chromium_win_pch': 1
  }
}

Removing the shared_library part fixed it. But the shared_library build probably
has to work!

The checked in ANGLE.sln build works either way of course.

[piman, 2011-10-20 22:40:26]

On Thu, Oct 20, 2011 at 3:24 PM, <apatrick@chromium.org> wrote:

> Hmm. Building ANGLE from the gyp generated VS projects I get errors
> like:
>
> 5>------ Rebuild All started: Project: essl_to_hlsl, Configuration:
> Debug Win32 ------
> 5>Deleting intermediate and output files for project 'essl_to_hlsl',
> configuration 'Debug|Win32'
> 5>Compiling...
> 5>debug.cpp
> 5>translator.cpp
> 5>Generating Code...
> 5>Compiling manifest to resources...
> 5>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
> 5>Copyright (C) Microsoft Corporation.  All rights reserved.
> 5>Linking...
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShInitBuiltInResources referenced in function "void __cdecl
> GenerateResources(struct ShBuiltInResources *)"
> (?GenerateResources@@**YAXPAUShBuiltInResources@@@Z)
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShFinalize referenced in function _main
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShDestruct referenced in function _main
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShGetObjectCode referenced in function _main
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShGetInfoLog referenced in function _main
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShGetInfo referenced in function _main
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShConstructCompiler referenced in function _main
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShInitialize referenced in function _main
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShCompile referenced in function "bool __cdecl CompileFile(char
> *,void *,int)" (?CompileFile@@YA_NPADPAXH@Z)
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShGetActiveUniform referenced in function "void __cdecl
> PrintActiveVariables(void *,enum ShShaderInfo,bool)"
> (?PrintActiveVariables@@**YAXPAXW4ShShaderInfo@@_N@Z)
> 5>translator.obj : error LNK2019: unresolved external symbol
> __imp__ShGetActiveAttrib referenced in function "void __cdecl
> PrintActiveVariables(void *,enum ShShaderInfo,bool)"
> (?PrintActiveVariables@@**YAXPAXW4ShShaderInfo@@_N@Z)
>
> I clobbered first. I had this in my include.gypi:
>
> {
>  'variables': {
>    'component': 'shared_library',
>    'chromium_win_pch': 1
>  }
> }
>
> Removing the shared_library part fixed it. But the shared_library build
> probably has to work!
>

Ok, we could make translator_hlsl a component too. I think that would fix
this.

Antoine

>
> The checked in ANGLE.sln build works either way of course.
>
>
http://codereview.appspot.com/**5305052/<http://codereview.appspot.com/5305052/>
>

[apatrick1, 2011-10-20 23:07:01]

With component=shared_library and that change.

1>------ Build started: Project: libGLESv2, Configuration: Debug Win32 ------
1>Linking...
1>LINK : fatal error LNK1181: cannot open input file
'..\build\debug\lib\translator_hlsl.lib'
1>libGLESv2 - 1 error(s), 0 warning(s)
2>------ Build started: Project: libEGL, Configuration: Debug Win32 ------
2>Linking...
2>LINK : fatal error LNK1181: cannot open input file
'..\build\debug\lib\libglesv2.lib'
2>libEGL - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 2 failed, 3 up-to-date, 0 skipped ==========

It's looking in the build/Debug/lib directory. For some reason the files are in
src/Debug/lib, which doesn't happen for when component=static_library.