Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Support using clang in mingw64 environment on Windows #4

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Tyler-IN
Copy link

@Tyler-IN Tyler-IN commented Aug 21, 2020

Primary goal:

  • Build and run JSC built with Clang under windows

  • Build and test JSC built with Clang and thin-LTO successfully under windows

Other stuff:

  • Support building without Udis86 / Disassembler

  • Support building release with (some) asserts

  • Use UASM instead of MASM

  • Drop UASM and MASM mostly or entirely if possible

  • Fix CPU guessing under Clang on Windows

  • Support building directly from sources instead of "unified sources"

Current CMake magic required to build, to be integrated into CMakeLists or other:

-G "Ninja"
-DRUBY_LIBRARY=/usr/bin/msys-ruby270.dll
-DCMAKE_BUILD_TYPE=Debug
-DINCLUDE_DIRECTORIES:STRING=/usr/include
-DCMAKE_CXX_FLAGS="-g -Og -flto=thin -fuse-ld=lld -fno-rtti -fno-exceptions -stdlib=libc++ -Wno-nonportable-include-path -Wno-ignored-attributes -Wno-implicit-int-float-conversion -UNDEBUG -D_DEBUG"
-DCMAKE_AR="C:\ProgramData\msys64\mingw64\bin\llvm-ar.exe"
-DCMAKE_RANLIB="C:\ProgramData\msys64\mingw64\bin\llvm-ranlib.exe"
-DCMAKE_LINKER="C:\ProgramData\msys64\mingw64\bin\ld.lld.exe --threads"
-DCMAKE_C_LINK_EXECUTABLE="C:\ProgramData\msys64\mingw64\bin\ld.lld.exe --threads"
-DCMAKE_CXX_LINK_EXECUTABLE="C:\ProgramData\msys64\mingw64\bin\ld.lld.exe --threads"
-DCMAKE_EXE_LINKER_FLAGS="-lc++ -lc++abi -lstdc++"
-DCMAKE_SHARED_LINKER_FLAGS="-lc++ -lc++abi -lstdc++"
-DCMAKE_ASM_MASM_COMPILER=uasm

TODO: Look into using CMAKE_SYSROOT, CMAKE_TOOLCHAIN_FILE

This is using Windows CMake instead of MSys/MinGW64 Cmake.

Also needs;

#ifdef __clang__
#define debug_break __builtin_debugtrap
#else
#include <Ultralight/private/util/DebugBreak.h> // or add it inside here
#endif

Source/JavaScriptCore/CMakeLists.txt Outdated Show resolved Hide resolved
Source/JavaScriptCore/dfg/DFGOSRExit.cpp Outdated Show resolved Hide resolved
Source/WTF/wtf/Assertions.h Outdated Show resolved Hide resolved
Source/WTF/wtf/CMakeLists.txt Outdated Show resolved Hide resolved
add_definitions(-D__STDC_CONSTANT_MACROS)

if (MSVC)
add_definitions(/bigobj)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add_definitions is outdated and has been replaced with newer commands. Maybe it can be replaced here then, see
https://cmake.org/cmake/help/latest/command/add_definitions.html for more information.

Copy link
Author

@Tyler-IN Tyler-IN Aug 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, add_compile_options, but add_definitions is used all over the place. Probably do a mass replace as a separate PR.

@@ -1,6 +1,6 @@
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_EXTENSIONS ON)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this is required? This should probably be off, as it allows compiler specific extensions to the language and can cause confusing errors.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I think this was an error

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From trying to build again, looks like this wasn't an error.

@@ -130,40 +130,50 @@ endif ()

# Check whether features.h header exists.
# Including glibc's one defines __GLIBC__, that is used in Platform.h
WEBKIT_CHECK_HAVE_INCLUDE(HAVE_FEATURES_H features.h)
if (NOT (${CMAKE_SYSTEM_NAME} STREQUAL "Windows"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this check is not a WIN32 check? (Same goes for the following ones)

Copy link
Author

@Tyler-IN Tyler-IN Aug 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think CMAKE_SYSTEM_NAME is for target, not for host.
Don't want to target Windows under Linux or Mac and assume these are available.

Copy link
Contributor

@Janrupf Janrupf Aug 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WIN32 is set to TRUE when targeting a Windows (like) system, so if you compile with MinGW under Linux, CMake will define WIN32.

It is also a bit weird that they have to be guarded at all. WEBKIT_CHECK_HAVE_INCLUDE checks if the include exists, and if it doesn't, it does not fail the compilation, but just sets the first argument of the macro to false. So even if those checks would be executed on every system, it should under no circumstances break the build.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The case I want to avoid is if they return true under Windows, not if they return false.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants