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.

[rhuanjl]

Nice to see the tests passing.

Did we actually need to increase the CMake minimum version? I would assume that if you run with the newer version (which you're going to be doing on newer macOS) it won't care that you report an earlier minimum version?

[ShortDevelopment]

Nice to see the tests passing.

Finally 🥳

Did we actually need to increase the CMake minimum version?

Yes. CMake applies different policies based on the specified min-version.

The pipeline for the last PR failed with the following message:

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.


-- Configuring incomplete, errors occurred!

Ubuntu 25.04 reports the following warning

CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.