-
Notifications
You must be signed in to change notification settings - Fork 26
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
Various windows fixes #181
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
lib/Interpreter/CppInterOp.cpp
Outdated
@@ -1084,7 +1084,7 @@ namespace Cpp { | |||
auto GD = GlobalDecl(VD); | |||
std::string mangledName; | |||
compat::maybeMangleDeclName(GD, mangledName); | |||
auto address = dlsym(/*whole_process=*/0, mangledName.c_str()); | |||
auto address = llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(mangledName.c_str()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
warning: 'auto address' can be declared as 'auto *address' [llvm-qualified-auto]
auto address = llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(mangledName.c_str()); | |
auto *address = llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(mangledName.c_str()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #181 +/- ##
==========================================
- Coverage 78.68% 78.67% -0.02%
==========================================
Files 8 8
Lines 3050 3053 +3
==========================================
+ Hits 2400 2402 +2
- Misses 650 651 +1
|
Codebase changes to be made in compiler-research#181 to allow Windows CI to pass
Can you rebase this PR? |
@fsfod In one of your future commits can you fix a mistake I made in the readme build instructions in my last PR. The following line
In my haste I copied from the ci and forgot to change it. |
sure |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
Its now just failing to find google test libs. |
@fsfod I also see this error in the CI. LINK : fatal error LNK1104: cannot open file 'pthread.lib' . pthreads seem to be unix only, so this also needs to be solved. |
Probably here we need to fix the library extensions: CppInterOp/cmake/modules/GoogleTest.cmake Lines 3 to 7 in aa3521b
|
Where does the lib path come from for linking thoses libs because it doesn't match that list. |
It is probably in |
The pthread library issue appears to be here https://github.com/fsfod/CppInterOp/blob/b59af225385cda1bf1936507eea8be07e2d71240/unittests/CMakeLists.txt#L27C1-L27C79 |
I believe the gtest library location is being set here on Windows. We are using the MSVC compiler in the CI, so I believe this is where the library path is being set. I'm not 100% certain though. |
Maybe something like: |
All those paths for point to |
The cling build of CppInterOp is now getting a large number of 'unresolved external symbol' errors after the last commit. Its not clear to me what may be causing it. |
All the gtest import paths are being set here. Maybe try changing in all the 4 paths This suggestion is working under the assumption that ${CMAKE_STATIC_LIBRARY_PREFIX} = lib/ I have to admit this is all kind of guess work on my part. |
I just figured that out, also ${CMAKE_STATIC_LIBRARY_PREFIX} is empty for windows |
I don't get any of those linker errors locally that there failing with now. Are the tests relying on symbol visibility for shared libraries being public? because for windows it private default and class or functions need to be explicitly annotated __declspec(dllexport) or the linker has to be passed file of mangled symbol names to be exported. |
Yes. LLVM has export_executable_symbols() but I think that’s mostly for executables. |
How is the symbol export solved for the llvm libraries on windows? |
I'm not really sure its fully solved for shared library builds https://discourse.llvm.org/t/supporting-llvm-build-llvm-dylib-on-windows/58891 |
…l in GetVariableOffset
Change clang::SmallVector to llvm::SmallVector and just set the smaller buffer size directly to 256 instead using platform defines
…ded by DynamicLibraryManager
…g for fs::real_path output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
I don't know but we could add a |
Probably not the best place to put this message, but sometime later today I will put in a PR to fix a few typos and mistakes in the README.md . |
Yes, let's merge this PR because it started to hit the cache limits in github and will be slow to make progress since it will start evicting caches for the builds... |
Fix some of the windows build errors, It still won't fully build with just these changes, but it gets it much closer.
I don't know much of the llvm internal API, but i did switched from some Linux specific function that were failing to build on windows with llvm API like SearchForAddressOfSymbol and real_path.