| View previous topic :: View next topic |
| Author |
Message |
motig
n00b
Joined: 11 Oct 2016
Posts: 39
|
 Posted: Sun Mar 31, 2024 7:58 pm Post subject: amd64 23.0 profile update - broken clang [SOLVED] |
 |
|
Greetings,
I have followed the upgrade steps on my fully updated system. I am using binpkgs for it. All has been going well until during emerge -e world got to chromium which uses clang. Apparently clang is broken:
| Code: |
# clang -v
clang version 17.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/17/bin
Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg
System configuration file directory: /etc/clang
Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/13
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
"/usr/bin/x86_64-pc-linux-gnu-ld.bfd" -pie --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/13/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/13 -L/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/lib -L/lib -L/usr/lib -z relro -z now -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/13/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64/crtn.o
/usr/bin/x86_64-pc-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64/Scrt1.o: in function `_start':
(.text+0x1b): undefined reference to `main'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
|
This "Scrt1.o" file seems to belong to glibc, which was emerged (binary) even before starting the emerge -e world, as per instructions. According to emerge.log, clang has already been reinstalled (binary). What could be the problem?
Thank you for any suggestions!
EDIT:
In the logs I can see that invokation of clang complains about libstdc++.so.6 "no such file or directory". However, ldd output seems fine:
| Code: |
$ ldd /usr/lib/llvm/17/bin/clang
linux-vdso.so.1 (0x00007ffc293fd000)
libclang-cpp.so.17 => /usr/lib/llvm/17/bin/../lib64/libclang-cpp.so.17 (0x00007eff9b40a000)
libLLVM-17.so => /usr/lib/llvm/17/bin/../lib64/libLLVM-17.so (0x00007eff93922000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6 (0x00007eff93696000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libgcc_s.so.1 (0x00007eff93671000)
libc.so.6 => /lib64/libc.so.6 (0x00007eff934ad000)
libm.so.6 => /lib64/libm.so.6 (0x00007eff933d0000)
/lib64/ld-linux-x86-64.so.2 (0x00007eff9ee2b000)
libffi.so.8 => /usr/lib64/libffi.so.8 (0x00007eff933c3000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00007eff933a1000)
libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x00007eff932eb000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007eff9329e000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007eff93147000)
liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007eff93115000)
libicuuc.so.74 => /usr/lib64/libicuuc.so.74 (0x00007eff92f28000)
libicudata.so.74 => /usr/lib64/libicudata.so.74 (0x00007eff911c8000)
|
Last edited by motig on Mon Apr 01, 2024 2:35 pm; edited 1 time in total |
|
| Back to top |
|
 |
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Sun Mar 31, 2024 9:54 pm Post subject: |
|
|
Note that clang -v giving an error is actually normal (on Gentoo, it's due to a clang limitation with its config files), and this does not mean clang is non-functional. So I'd suggest not paying attention that while trying to figure out what went wrong with chromium.
Providing emerge --info, and chromium's (complete) build.log to see what happened exactly would be more useful for starters. |
|
| Back to top |
|
|
e8root
Tux's lil' helper
Joined: 09 Feb 2024
Posts: 77
|
| Posted: Mon Apr 01, 2024 3:52 am Post subject: |
|
|
In case of doubt it is good to have clang profile in env and verify with some small but best having few source files program. I usually rebuild xterm. To debug some compiler issues it can also help to build helloworld.c and running it
Chromium is one of the largest packages you can build (larger than kernel and whole stage3 tarball including gcc) so there is lots and lots of things which can go wrong including trivial but oh so irritating issues like computer itself not being 100% stable.
Pro tip: When you build package and it fails and you are not quite sure what is the error you can continue compilation by ebuild /var/db/repos/gentoo/${PACKAGE_CATEGORY}/{$PACKAGE_NAME}/${PACKAGE_NAME}{$PACKAGE_VERSION}.ebuild compile
It might be that if the compiler error looks like some kind of random segfault and it magically completes after few compile retries then it is hardware issue or you need to tweak UEFI/BIOS settings. If not and it consistently fails in one place then using this trick will help you nail the error message down.
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
|
motig
n00b
Joined: 11 Oct 2016
Posts: 39
|
| Posted: Mon Apr 01, 2024 8:34 am Post subject: |
|
|
| Ionen wrote: | | Note that clang -v giving an error is actually normal (on Gentoo, it's due to a clang limitation with its config files), and this does not mean clang is non-functional. |
That is interesting - on another Gentoo machine which has not been updated yet (with clang 16 and profile 17.1) it does not give any error. I had to delete the chromium build directory and get on with the compilation, I can keep the Chromium update for later since it takes so long and is not a priority for a functional system.
Firefox also gave me that error so I'm starting to suspect some discrepancy between clang on different hosts since I am using icecream to distribute the compilation jobs. At first I discarded that idea because during the world update I had done just before switching profile, everything went smoothly. The versions have not changed with the 23.0 rebuild. In any case, I will run the Firefox emerge locally as soon as the other packages have been updated. I did not want to do it with Chromium (only as a last resort) since a local build takes ~20 hours.
I will post an update as soon as I have the results. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Mon Apr 01, 2024 11:31 am Post subject: |
|
|
| motig wrote: | | Ionen wrote: | | Note that clang -v giving an error is actually normal (on Gentoo, it's due to a clang limitation with its config files), and this does not mean clang is non-functional. |
That is interesting - on another Gentoo machine which has not been updated yet (with clang 16 and profile 17.1) it does not give any error |
That's because the configuration file I speak of was introduced with clang-common-17, so clang 16 is not affected.
If you're interested in seeing the error go away, temporarily comment out the -Wl options in /etc/clang/gentoo-hardened-ld.cfg. Thing is that clang will attempt to use these options even when using clang -v. Hopefully this will be improved in the future, but for now it can be ignored (so please keep the options).
You can try it with gcc too: | Code: | $ gcc -v
...
gcc version 13.2.1 20240210 (Gentoo 13.2.1_p20240210 p14)
$ gcc -v -Wl,-z,now
[...]
collect2: error: ld returned 1 exit status |
gcc will also do -z,now by default but does not attempt to use it with -v unless you pass it yourself.
Edit: That aside, if you want an error-free clang version regardless, do clang --version instead. |
|
| Back to top |
|
|
motig
n00b
Joined: 11 Oct 2016
Posts: 39
|
| Posted: Mon Apr 01, 2024 2:34 pm Post subject: |
|
|
Thank you for the tips. 
I have verified that clang works as expected on the machine and was successfully able to build Firefox locally. I will migrate the other machines on the network to profile version 23.0 first, before attempting to recompile Chromium (which hopefully solves the distributed build problem). |
|
| Back to top |
|
|
|
Portage & Programming
