990333 - build failure: make11176-1.sh: line 1: syntax error near unexpected token `(', recipe for target 'libGLESv2.dll' failed

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: log.txt

I get a build error on Win8.1:

0:36.58 C:/Users/cpearce/AppData/Local/Temp/make11176-1.sh: line 1: syntax error near unexpected token `('
 0:36.58 C:/Users/cpearce/AppData/Local/Temp/make11176-1.sh: line 1: `c:/Users/cpearce/src/mozilla/central/objdir/_virtualenv/Scripts/python.exe c:/Users/cpearce/src/mozilla/central/config/expandlibs_exec.py --depend .deps/libGLESv2.dll.pp --target libGLESv2.dll --uselist -- link -NOLOGO -DLL -OUT:libGLESv2.dll -PDB:libGLESv2.pdb -SUBSYSTEM:WINDOWS -MACHINE:X86  DiagnosticsBase.obj DirectiveHandlerBase.obj DirectiveParser.obj ExpressionParser.obj Input.obj Lexer.obj Macro.obj MacroExpander.obj Preprocessor.obj Token.obj Tokenizer.obj BuiltInFunctionEmulator.obj Compiler.obj compiler_debug.obj CompilerUniform.obj DetectCallDepth.obj Diagnostics.obj DirectiveHandler.obj ForLoopUnroll.obj glslang_lex.obj glslang_tab.obj InfoSink.obj Initialize.obj InitializeDll.obj InitializeParseContext.obj Intermediate.obj intermOut.obj IntermTraverse.obj MapLongVariableNames.obj parseConst.obj ParseHelper.obj PoolAlloc.obj QualifierAlive.obj RemoveTree.obj SymbolTable.obj util.obj ValidateLimitations.obj VariableInfo.obj VariablePacker.obj DependencyGraph.obj DependencyGraphBuilder.obj DependencyGraphOutput.obj DependencyGraphTraverse.obj RestrictFragmentShaderTiming.obj RestrictVertexShaderTiming.obj ArrayBoundsClamper.obj MurmurHash3.obj ossource_win.obj CodeGenHLSL.obj DetectDiscontinuity.obj OutputHLSL.obj SearchSymbol.obj ShaderLang.obj TranslatorHLSL.obj UnfoldShortCircuit.obj debug.obj RefCountObject.obj Buffer.obj Context.obj Fence.obj Float16ToFloat32.obj Framebuffer.obj HandleAllocator.obj libGLESv2.obj main.obj precompiled.obj Program.obj ProgramBinary.obj Query.obj Renderbuffer.obj ResourceManager.obj Shader.obj Texture.obj Uniform.obj utilities.obj Blit.obj BufferStorage.obj BufferStorage11.obj BufferStorage9.obj Fence11.obj Fence9.obj Image.obj Image11.obj Image9.obj ImageSSE2.obj IndexBuffer.obj IndexBuffer11.obj IndexBuffer9.obj IndexDataManager.obj IndexRangeCache.obj InputLayoutCache.obj Query11.obj Query9.obj Renderer.obj Renderer11.obj renderer11_utils.obj Renderer9.obj renderer9_utils.obj RenderStateCache.obj RenderTarget11.obj RenderTarget9.obj ShaderExecutable11.obj ShaderExecutable9.obj SwapChain11.obj SwapChain9.obj TextureStorage.obj TextureStorage11.obj TextureStorage9.obj VertexBuffer.obj VertexBuffer11.obj VertexBuffer9.obj VertexDataManager.obj VertexDeclarationCache.obj  ./module.res -LARGEADDRESSAWARE -NXCOMPAT -DYNAMICBASE -SAFESEH  -DEBUG -DEBUGTYPE:CV  -DEF:c:/Users/cpearce/src/mozilla/central/gfx/angle/src/libGLESv2/libGLESv2.def     C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/lib/x86/d3d9.lib C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/lib/x86/dxguid.lib delayimp.lib c:/Users/cpearce/src/mozilla/central/objdir/dist/lib/mozglue.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib secur32.lib netapi32.lib    '
 0:36.58 c:/Users/cpearce/src/mozilla/central/config/rules.mk:885: recipe for target 'libGLESv2.dll' failed
 0:36.58 mozmake.EXE[5]: *** [libGLESv2.dll] Error 258
 0:36.58 mozmake.EXE[5]: Leaving directory 'c:/Users/cpearce/src/mozilla/central/objdir/gfx/angle/src/libGLESv2'
 0:36.58 c:/Users/cpearce/src/mozilla/central/config/recurse.mk:95: recipe for target 'gfx/angle/src/libGLESv2/libs' failed
 0:36.58 mozmake.EXE[4]: *** [gfx/angle/src/libGLESv2/libs] Error 2
 0:36.58 mozmake.EXE[4]: Leaving directory 'c:/Users/cpearce/src/mozilla/central/objdir'
 0:36.58 c:/Users/cpearce/src/mozilla/central/config/recurse.mk:39: recipe for target 'libs' failed
 0:36.58 mozmake.EXE[3]: *** [libs] Error 2
 0:36.58 mozmake.EXE[3]: Leaving directory 'c:/Users/cpearce/src/mozilla/central/objdir'
 0:36.59 c:/Users/cpearce/src/mozilla/central/config/rules.mk:592: recipe for target 'default' failed
 0:36.59 mozmake.EXE[2]: *** [default] Error 2
 0:36.59 mozmake.EXE[2]: Leaving directory 'c:/Users/cpearce/src/mozilla/central/objdir'
 0:36.59 c:/Users/cpearce/src/mozilla/central/client.mk:398: recipe for target 'realbuild' failed
 0:36.59 mozmake.EXE[1]: *** [realbuild] Error 2
 0:36.59 mozmake.EXE[1]: Leaving directory 'c:/Users/cpearce/src/mozilla/central'
 0:36.59 client.mk:185: recipe for target 'build' failed
 0:36.59 mozmake.EXE: *** [build] Error 2
 0:36.60 856 compiler warnings present.
2

`./mach build -v` output attached.

I'm on Win8.1, I'm using Mozillabuild 1.9 pre, I have Visual Studio 2010 and 2012 installed, though I'm building with 2010 only. I have the DirectX June 2010 SDK. This just broke when I updated just now, I'll see if I can narrow a regression range. I get the exact same error when I build on another Win8.1 computer here.

$ hg tip
changeset:   176283:df7b26e90378
tag:         tip
parent:      176242:723177fe1452
parent:      176282:16ab4bb818c9
user:        Ryan VanderMeulen <[e-mail]>
date:        Mon Mar 31 17:27:57 2014 -0400
summary:     Merge b2g-inbound to m-c.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

This is a regression from 7807eb511741, bug 961665.

Jacek: Any ideas?

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Chris Pearce (:cpearce) from comment #1)
> This is a regression from 7807eb511741, bug 961665.

Whoops, this is actually a regression from c7f461dce4c9, bug 988271.

Jacek: Any ideas?

Comment 3

[Mike Hommey [:glandium]]

Attachment: Fix DirectX SDK path handling when linking xul.dll after bug 988271

Chris, please test this.

Comment 4

[Mike Hommey [:glandium]]

Attachment: Fix DirectX SDK path handling when linking xul.dll after bug 988271

Was missing a change to another file.

Comment 5

[Marco Zehe (:MarcoZ)]

Also affected by this since I chose to accept the default location of "C:\Program Files (X86)\..."

Comment 6

[Jacek Caban]

Attachment: EXPAND_LIBNAME_PATH change

First of all, I'm sorry for introducing the bug.

Could we fix EXPAND_LIBNAME_PATH instead?

Comment 7

[Michael Shal [:mshal]]

Comment on attachment 8399847 [details] [diff] [review]
Fix DirectX SDK path handling when linking xul.dll after bug 988271

This is fine, though I think jacek's approach would help us avoid similar issues in the future.

Comment 8

[Philip Chee]

Comment on attachment 8399847 [details] [diff] [review]
Fix DirectX SDK path handling when linking xul.dll after bug 988271

> --- a/toolkit/library/libxul.mk
> +++ b/toolkit/library/libxul.mk
This file does not exist on tip.

However there is this line in /toolkit/library/Makefile.in that you should be patching instead.

> OS_LIBS += $(call EXPAND_LIBNAME_PATH,dxguid dinput8, $(subst \,/,$(MOZ_DIRECTX_SDK_PATH))/Lib/$(MOZ_DIRECTX_SDK_CPU_SUFFIX))

Comment 9

[Michael Shal [:mshal]]

(In reply to Philip Chee from comment #8)
> Comment on attachment 8399847 [details] [diff] [review]
> Fix DirectX SDK path handling when linking xul.dll after bug 988271
> 
> > --- a/toolkit/library/libxul.mk
> > +++ b/toolkit/library/libxul.mk
> This file does not exist on tip.
> 
> However there is this line in /toolkit/library/Makefile.in that you should
> be patching instead.
> 
> > OS_LIBS += $(call EXPAND_LIBNAME_PATH,dxguid dinput8, $(subst \,/,$(MOZ_DIRECTX_SDK_PATH))/Lib/$(MOZ_DIRECTX_SDK_CPU_SUFFIX))

The libxul.mk file was introduced in bug 988168, which is currently in inbound. Assuming it sticks, it should be on tip shortly!

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Jacek Caban from comment #6)
> Created attachment 8399909 [details] [diff] [review]
> EXPAND_LIBNAME_PATH change
> 
> First of all, I'm sorry for introducing the bug.
> 
> Could we fix EXPAND_LIBNAME_PATH instead?

This didn't fix the build for me, but glandium's patch did.

Comment 11

[Mike Hommey [:glandium]]

Comment on attachment 8399909 [details] [diff] [review]
EXPAND_LIBNAME_PATH change

Review of attachment 8399909 [details] [diff] [review]:
-----------------------------------------------------------------

While this is theoretically better (albeit kind of ugly for the rules.mk change), since a) it apparently doesn't solve the problem cf. comment 10, and b) those EXTRA_DSO_LDOPTS and OS_LIBS things are likely to go away rather sooner than later, I'll just land my patch.

Comment 12

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c70621a3019c

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c70621a3019c