1596971 - Unable to compile Windows shell

Status: RESOLVED DUPLICATE of bug 1598709

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: build failure log

I noticed Windows shell builds were failing to compile recently on a machine for me.

'LIBCLANG_PATH=c:\Users\gkweyeniner\.mozbuild\clang\bin' MAKE=mozmake sh c://Users//<username>//trees//mozilla-central//js//src//configure --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-debug --enable-more-deterministic --without-intl-api --enable-gczeal --enable-debug-symbols --disable-tests

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/0ae96da6fdb2
user: Philip Chimento
date: Sun Oct 27 22:34:11 2019 +0000
summary: Bug 1426865 - Add default visibility to JSAPI symbols. r=sfink

Philip/Steve, is bug 1426865 a likely regressor?

Tested on Windows 10 1909, using MozillaBuild 3.3 and seemed to happen on both SDK versions 10.0.18362.0 and 10.0.17763.0. I think the build with Intl enabled also fail too.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

$ ~/.mozbuild/clang/bin/clang.exe --version
clang version 9.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: c:\Users\gkweyeniner\.mozbuild\clang\bin

clang-cl seems to show a similar thing. I had run mach bootstrap right before.

Comment 2

[Philip Chimento [:ptomato]]

It's hard to tell. It certainly seems like it could be the cause since it has to do with symbol visibility. However, that method looks like it is supposed to be defined inline by including BytecodeLocation-inl.h so I suppose it makes sense that it's not present in the object file?

Relevant part of the log:

js/src/build/mozjs-72a1.dll
lld-link: error: undefined symbol: public: bool __cdecl js::BytecodeLocation::isValid(class JSScript const *) const
>>> referenced by c:\Users\gkweyeniner\trees\mozilla-central\js\src\vm\JSScript.h:2548
>>>               ..\RegExp.obj:(public: class js::BytecodeLocation __cdecl JSScript::location(void))
>>> referenced by c:\Users\gkweyeniner\trees\mozilla-central\js\src\vm\JSScript.h:2949
>>>               ..\RegExp.obj:(public: class js::BytecodeLocation __cdecl JSScript::mainLocation(void) const)
>>> referenced by c:\Users\gkweyeniner\trees\mozilla-central\js\src\vm\JSScript.h:2953
>>>               ..\RegExp.obj:(public: class js::BytecodeLocation __cdecl JSScript::endLocation(void) const)
>>> referenced by c:\Users\gkweyeniner\trees\mozilla-central\js\src\vm\JSScript.h:2957
>>>               ..\RegExp.obj:(public: class js::BytecodeLocation __cdecl JSScript::offsetToLocation(unsigned int) const)
>>> referenced by ..\jsmath.obj
>>> referenced by ..\jsutil.obj
>>> referenced by ..\Interpreter.obj
>>> referenced by ..\TraceLogging.obj
>>> referenced by ..\VTuneWrapper.obj
>>> referenced by ..\Unified_cpp_js_src0.obj
>>> referenced 54 more times

Location of that method: https://searchfox.org/mozilla-central/source/js/src/vm/BytecodeLocation-inl.h#17

Is there a CI job that builds this configuration that would have caught this? (I don't have a Windows machine to test it on.)

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I can test patches for you. I think :sfink knows more about Windows CI builds though.

Comment 4

[Steve Fink [:sfink] [:s:]]

Oops. I looked at this, saw something very wrong, and fixed it separately after having forgotten it was from this bug. So the patch should be here, but it's on bug 1598709 instead, so I'm duping this one.