From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Othacehe Subject: bug#37999: clang fails to pickup/supply startfiles to ld Date: Thu, 31 Oct 2019 08:55:27 +0100 Message-ID: <878sp1pcwg.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:53339) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQ5JM-0001qB-5y for bug-guix@gnu.org; Thu, 31 Oct 2019 03:56:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iQ5JK-0002Re-MB for bug-guix@gnu.org; Thu, 31 Oct 2019 03:56:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:43261) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iQ5JK-0002R6-BV for bug-guix@gnu.org; Thu, 31 Oct 2019 03:56:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iQ5JK-0006cL-8M for bug-guix@gnu.org; Thu, 31 Oct 2019 03:56:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Carl Dong Cc: 37999@debbugs.gnu.org --=-=-= Content-Type: text/plain Hello Carl, The attached patch fixes it for me, but this piece of code should be rewritten so that we don't have the same failure at every clang major version update. WDYT? Mathieu --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-gnu-clang-from-llvm-Fix-linking.patch >From ac0cf4e25f9acdb02bee402b45a8f31a4830fcb7 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Thu, 31 Oct 2019 08:52:39 +0100 Subject: [PATCH] gnu: clang-from-llvm: Fix linking. * gnu/packages/llvm.scm (clang-from-llvm)[arguments]: Support clang 8 in set-glibc-file-names phase. --- gnu/packages/llvm.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm index 9a42d4fe07..46f35434a1 100644 --- a/gnu/packages/llvm.scm +++ b/gnu/packages/llvm.scm @@ -204,7 +204,7 @@ compiler. In LLVM this library is called \"compiler-rt\".") (compiler-rt (assoc-ref inputs "clang-runtime"))) (case (string->number ,(version-major (package-version clang-runtime))) - ((or 6 7) + ((or 6 7 8) ;; Link to libclang_rt files from clang-runtime. (substitute* "lib/Driver/ToolChain.cpp" (("getDriver\\(\\)\\.ResourceDir") -- 2.23.0 --=-=-= Content-Type: text/plain Carl Dong writes: > Hi all, > > Our clang toolchain seems to be quite broken at this time. In particular, it > fails to call `ld` in the right way such that the startfiles are picked up: > > --8<---------------cut here---------------start------------->8--- > $ guix environment --pure --container --ad-hoc clang@6 binutils -- clang++ -v -Xlinker --verbose > ... > "/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld" > --eh-frame-hdr > -m elf_x86_64 > -dynamic-linker /lib64/ld-linux-x86-64.so.2 > -o a.out > crt1.o > crti.o > /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/crtbegin.o > -L/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0 > -L/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../.. > -L/gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib > --verbose > -L/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib > -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc > /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/crtend.o > crtn.o > ... > attempt to open crt1.o failed > /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find crt1.o: No such file or directory > attempt to open crti.o failed > /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find crti.o: No such file or directory > ... > attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/libm.so failed > attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/libm.a failed > attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../../libm.so failed > attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../../libm.a failed > attempt to open /gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib/libm.so failed > attempt to open /gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib/libm.a failed > attempt to open /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib/libm.so failed > attempt to open /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib/libm.a failed > attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib64/libm.so failed > attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib64/libm.a failed > attempt to open /no-ld-lib-path/libm.so failed > attempt to open /no-ld-lib-path/libm.a failed > attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib/libm.so failed > attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib/libm.a failed > /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find -lm > ... > --8<---------------cut here---------------end--------------->8--- > > I believe this is because we have crt1.o, crti.o, and limb.so in the output of > our glibc package, which clang seems unaware of. > > I don't know exactly how to fix this, but I did some digging in the clang > codebase (cfe-6.0.1 to be exact), and found that the crt1.o, crti.o arguments > are added in lib/Driver/ToolChains/Gnu.cpp. > > These arguments are constructed using something like > Args.MakeArgString(ToolChain.GetFilePath("crti.o")), which really calls > Driver::GetFilePath in lib/Driver/Driver.cpp under the hood. Meaning that we > just need to make Driver::GetFilePath aware of our glibc path and return the > correct full path to crt1.o and crti.o. > > If anyone can help out here it would be much appreciated. > > Cheers, > Carl Dong > contact@carldong.me > "I fight for the users" --=-=-=--