fix: MacOS build

[ShortDevelopment]

Issues

• Modern MacOS only supports CMake >= 3.10.
• Modern libICU requires c++17
• clang reports an invalid CFI advance_loc expression

Changes

• Upgrade to CMake 3.10
• Set EMBED_ICU to pin libicu for now
• Ensure labels for local jumps are "private" using our own LOCAL_LABEL definition
  https://gitlab.winehq.org/wine/wine/-/merge_requests/4547
  

  ChakraCore/pal/inc/unixasmmacros.inc

  Lines 8 to 16 in 22f1619

  	#if defined(__APPLE__)
  	#define C_FUNC(name) _##name
  	#define EXTERNAL_C_FUNC(name) C_FUNC(name)
  	#define LOCAL_LABEL(name) L##name
  	#else
  	#define C_FUNC(name) name
  	#define EXTERNAL_C_FUNC(name) C_FUNC(name)@plt
  	#define LOCAL_LABEL(name) .L##name
  	#endif

---

Fixes #7031

[rhuanjl]

Looking at the Linux CI log, it looks like ch or chakracore is crashing when being asked to regen the bytecode on Linux.

The python regen script writes a prologue to the file then calls ch with certain parameters to produce the bytecode - the line where the "error" is being found is the line where the prologue ends and the generated material starts. Nothing is being generated hence the mismatch.

This is the first test that runs so it could be that it's not a problem specific to bytecode regen but that either the ch or chakracore build is broken and doesn't run at all.

Are you able to test offline? I have no Linux setup at the moment, so cannot easily test (would need to make a vm)

Ideally would try running offline with a debugger attached and find where ch or chakracore is crashing (or at least why it's closing with no output)

[ShortDevelopment]

Interestingly I would expect the regenByteCode.py tool to output some error:

ChakraCore/tools/regenByteCode.py

Lines 138 to 142 in 22f1619

	if job.returncode != 0:
	print(error)
	print('Command line: ')
	print(*command_with_file)
	sys.exit(1)

[ShortDevelopment]

So it turns out that the ByteCode gen fails because ./ch cannot read the input file.

The filename is set by

ChakraCore/bin/ch/ChakraRtInterface.cpp

Line 266 in 22f1619

hr = GetFileNameFlag(&fileNameWide);

called by

ChakraCore/bin/ch/ChakraRtInterface.cpp

Line 241 in 22f1619

HRESULT ChakraRTInterface::ParseConfigFlags()

called by

ChakraCore/bin/ch/ch.cpp

Lines 45 to 49 in 22f1619

	extern "C"
	HRESULT __stdcall OnChakraCoreLoadedEntry(TestHooks& testHooks)
	{
	return ChakraRTInterface::OnChakraCoreLoaded(testHooks);
	}

called by

ChakraCore/bin/ChakraCore/TestHooks.cpp

Lines 148 to 157 in 22f1619

	HRESULT OnChakraCoreLoaded(OnChakraCoreLoadedPtr pfChakraCoreLoaded)
	{
	if (pfChakraCoreLoaded == nullptr)
	{
	pfChakraCoreLoaded = (OnChakraCoreLoadedPtr)GetProcAddress(GetModuleHandle(NULL), "OnChakraCoreLoadedEntry");
	if (pfChakraCoreLoaded == nullptr)
	{
	return S_OK;
	}
	}

but ./ch does not export OnChakraCoreLoadedEntry any more (that's broken by this PR)

[rhuanjl]

Interestingly I would expect the regenByteCode.py tool to output some error:

ChakraCore/tools/regenByteCode.py

Lines 138 to 142 in 22f1619

	if job.returncode != 0:
	print(error)
	print('Command line: ')
	print(*command_with_file)
	sys.exit(1)

That error display has been unreliable in the past - ideally should fix it...

[rhuanjl]

So it turns out that the ByteCode gen fails because ./ch cannot read the input file.

The filename is set by

ChakraCore/bin/ch/ChakraRtInterface.cpp

Line 266 in 22f1619

hr = GetFileNameFlag(&fileNameWide);

called by

ChakraCore/bin/ch/ChakraRtInterface.cpp

Line 241 in 22f1619

HRESULT ChakraRTInterface::ParseConfigFlags()

called by

ChakraCore/bin/ch/ch.cpp

Lines 45 to 49 in 22f1619

	extern "C"
	HRESULT __stdcall OnChakraCoreLoadedEntry(TestHooks& testHooks)
	{
	return ChakraRTInterface::OnChakraCoreLoaded(testHooks);
	}

called by

ChakraCore/bin/ChakraCore/TestHooks.cpp

Lines 148 to 157 in 22f1619

	HRESULT OnChakraCoreLoaded(OnChakraCoreLoadedPtr pfChakraCoreLoaded)
	{
	if (pfChakraCoreLoaded == nullptr)
	{
	pfChakraCoreLoaded = (OnChakraCoreLoadedPtr)GetProcAddress(GetModuleHandle(NULL), "OnChakraCoreLoadedEntry");
	if (pfChakraCoreLoaded == nullptr)
	{
	return S_OK;
	}
	}

but ./ch does not export OnChakraCoreLoadedEntry any more (that's broken by this PR)

Seems like very strange breakage for simply changing the cmake version - does the export somehow depend on a deprecated cmake feature? I can't remember if that logic is something I've ever looked at.

[ShortDevelopment]

CMake 3.4 introduced CMAKE_ENABLE_EXPORTS to enable exports from executables.