Fix linker not finding pthreads or dl #435
Conversation
|
@RLovelett Thank you for working on this! I think the issue is that the current CMake scripts are set up in such a way that the results produced by May I ask you to try changing |
|
Your enthusiasm makes me think that this was something you were aware of. Glad I'm not barking up the wrong tree completely. I think I've got your suggestions working. I'm building from scratch in a VM right now (it is slow). I'm new to CMake; who knew |
|
I just find the current master is OK to build under my arch(sync to latest) (with py2 lib patching). No flag patching is need any more. |
|
I can confirm that I am seeing the same thing. I want to run |
|
Ok I give up. I cannot even reproduce the compiler error anymore going back to |
|
Like a phoenix rising from the ashes this bug is back. When trying to build commit 48ec67c I am getting this error again. So I resurrected my patches from before with @gribozavr's suggestions and it is compiling again. Voila! DiscussionAs @gribozavr suggested I made While debugging I made two CMake BeforeAfter |
RLovelett
force-pushed
the
linking-pthreads-and-dl
branch
2 times, most recently
from
758a2f2
to
9756d23
Compare
|
@gribozavr I still don't think this is a complete patch because there are at least two other uses of I'm pretty sure I know how to fix them; duplicate the code that I already wrote for those two places. The problem is I don't know how to test it. Do you have any suggestions? |
RLovelett
force-pushed
the
linking-pthreads-and-dl
branch
2 times, most recently
from
94cb2d7
to
aa91ecd
Compare
| @@ -1119,6 +1122,8 @@ function(_add_swift_library_single target name) | |||
| set_property(TARGET "${target}" APPEND_STRING PROPERTY | |||
| LINK_FLAGS " ${link_flags} -L${SWIFTLIB_DIR}/${SWIFTLIB_SINGLE_SUBDIR} -L${SWIFT_NATIVE_SWIFT_TOOLS_PATH}/../lib/swift/${SWIFTLIB_SINGLE_SUBDIR} -L${SWIFT_NATIVE_SWIFT_TOOLS_PATH}/../lib/swift/${SWIFT_SDK_${SWIFTLIB_SINGLE_SDK}_LIB_SUBDIR}") | |||
| target_link_libraries("${target}" PRIVATE | |||
| ${link_libs}) | |||
| target_link_libraries("${target}" PRIVATE | |||
| ${SWIFTLIB_SINGLE_PRIVATE_LINK_LIBRARIES}) | |||
There was a problem hiding this comment.
I think you can do:
target_link_libraries("${target}" PRIVATE
${SWIFTLIB_SINGLE_PRIVATE_LINK_LIBRARIES}
${link_libs})
|
@RLovelett It looks like we are not using The other function is used out-of-tree. Just use the same pattern, and I will test before merging. Thanks! |
RLovelett
force-pushed
the
linking-pthreads-and-dl
branch
2 times, most recently
from
36f6bcc
to
acaa5ea
Compare
|
I think I've incorporated the feedback and I have rebased on the latest master. EDIT: I also made merge request #740 that removes |
This function was discovered to be unused during the review of apple#435. It was requested that it be removed as a subsequent pull.
RLovelett
force-pushed
the
linking-pthreads-and-dl
branch
2 times, most recently
from
ebbae91
to
0141340
Compare
|
Sadly I no longer thing this is working right. EDIT: I still think it solves this problem I just think it introduces another one. One that is completely beyond my depth to solve. On my latest build after applying this patch to If I go back to my original patch: diff --git a/cmake/modules/AddSwift.cmake b/cmake/modules/AddSwift.cmake
index c523924..a5accca 100644
--- a/cmake/modules/AddSwift.cmake
+++ b/cmake/modules/AddSwift.cmake
@@ -150,7 +150,7 @@ function(_add_variant_link_flags
result)
if("${sdk}" STREQUAL "LINUX")
- list(APPEND result "-lpthread" "-ldl")
+ list(APPEND result "-pthread" "-lpthread" "-ldl")
elseif("${sdk}" STREQUAL "FREEBSD")
# No extra libraries required.
else()
diff --git a/stdlib/public/core/CMakeLists.txt b/stdlib/public/core/CMakeLists.txt
index 5e44d5c..2de407a 100644
--- a/stdlib/public/core/CMakeLists.txt
+++ b/stdlib/public/core/CMakeLists.txt
@@ -162,6 +162,7 @@ if(CMAKE_SYSTEM_NAME STREQUAL "Linux")
find_package(BSD REQUIRED)
list(APPEND swift_core_private_link_libraries
${BSD_LIBRARIES})
+ list(APPEND swift_core_private_link_libraries "-lpthread" "-ldl")
endif()
option(SWIFT_CHECK_ESSENTIAL_STDLIBI don't get the segfault. 😞 |
|
I have done a fresh build yesterday. I continue to get building done successfully without any patching... It is best that to make cmake to find the right options by itself, if we really have to patch. but again, do we really get the exact reason the bug back? or some mistake? |
RLovelett
force-pushed
the
linking-pthreads-and-dl
branch
from
0141340
to
d6889e3
Compare
RLovelett
force-pushed
the
linking-pthreads-and-dl
branch
from
d6889e3
to
f60b7bd
Compare
On Arch linux the linker was not seeing the `-lpthread` or `-ldl` linker flags. This patch resolves it by specifically seperating link libraries from linker flags returned by _add_variant_link_flags method. Then applying the link libraries using CMake's target_link_libraries function.
RLovelett
force-pushed
the
linking-pthreads-and-dl
branch
from
f60b7bd
to
5859a5c
Compare
|
Progress! I tried running this branch on OS X. There is good news and bad news. The bad news is that this branch is now confirmed to not work on OS X too. The good news is the segmentation fault does not occur with the OS X version of Unfortunately, I do not know what that means or how to solve it. But now I at least have something I can search the internet for. |
|
That looks like the build was supposed to pass |
|
The impetus for this patch initially was the not finding I've continued to run this to ground to determine the root cause and I believe I've found the smoking gun. I'll spare all the gory details and just cut to the chase. @jinmingjian was right there is no compilation issue on Arch. It's more precise to say there is a linker issue when building in a package build. Basically if you the build inside of a Once removing this definition the build succeeds as expected. Or conversely adding this to the environment causes it to fail. Perhaps this is a bug? (If it is I'm not sure if is in Arch, Swift or both) Not sure what this means but I thought I'd continue to document this. |
|
I've run into this issue as well. I talked to someone more knowledgeable about the Arch build system than me and might not relate this correctly, so take all this with a grain of salt: The default I think this might be the cause of the problem, and should probably be fixed in the Swift cmake files, although I don't know where and how, since I am not very familiar with cmake. |
|
I would be happy to merge the fix, if someone can reliably reproduce the issue and test the fix. |
Update hash for Base64CoderSwiftUI, remove xfail
On Arch Linux the
clang++linker is ignoring/not seeing the-lpthreador-ldllinker flags. This patch resolves it by adding-pthreadsflag to theclang++arguments and by specifying it again inside ofstdlib. I won't claim that this is the best solution. I'll just say it is a solution that I have found to work. I'm just beginning to learncmakeso I wasn't sure how to just move the-lpthreadand-ldlflags to either the beginning or the end of the argument list.Ultimately the thing that has me the most puzzled is why clang cannot see the flags without the patch... They are clearly there in the arguments (checkout allout.txt for a full build log). What is more is if I manually move them to either the beginning or the end of the argument list then it links. I'm by no means a clang expert so this may be expected behavior.
Arch
clang++version:Motivation
I first started questioning the issue on the mailing list.
The original error that this attempts to solve: