Talk:Clang
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 12:49, 5 November 2024 (UTC) :: Your reply ~~~~
"Installation" doesn't actually cover installation
I'd like to give Clang a try, but none of the documentation I've run across (including this page) provides up-to-date installation instructions. Most of what I've seen appears to cover older versions, not v4.0. I already had LLVM installed as a prerequisite for something else, but that by itself doesn't bring in Clang. Turns out there's a separate Clang ebuild, so I installed that...but it installs nothing in /usr/bin. Maybe there's something similar to gcc-config or eselect that needs to be invoked...but I can't find so much as a mention of it.
--Salfter (talk) 15:21, 23 March 2017 (UTC)
- I added some instructions. With that being said, this article expects anyone messing around with changing your default compiler on Gentoo should have a certain understanding of USE flags. --Maffblaster (talk) 17:08, 23 March 2017 (UTC)
Tried that...euse -E clang returned an error since clang isn't defined in use.desc. I added it manually anyway and set off a rebuild...it didn't find anything to do, as both llvm and clang are already installed. Looking at the USE flags the llvm 4.0.0 ebuild recognizes, clang isn't among them. clang appears to have been pulled in by other ebuilds already, such as media-libs/mesa...but why isn't the clang ebuild either putting executables in /usr/bin or modifying PATH so that the executables show up under it?
--Salfter (talk) 18:04, 23 March 2017 (UTC)
Some ideas
Hey! Here are some ideas...
- I think it'd be great to include on the wiki a few examples of packages that do compile fine with Clang. That would help newbies start using it (without the risk of messing up their system).
- Also, perhaps you could have an FAQ with questions like, "Should I file a bug if the package fails to build with Clang? If not, is there some place I should report it?"
- Would it be kosher to post a link on this wiki to http://en.gentoo-wiki.com/wiki/Llvm ?
- David 15:51, 13. May 2012 (UTC)
- As to your (3), yes, it is allowed to link to external resources. It would be even better to make a page in the wiki here with all relevant information. — yngwin 07:36, 15 June 2012 (UTC)
- There are no items to action in discussion that the community can't do (if they care). I'm closing it. --Maffblaster (talk) 17:09, 23 March 2017 (UTC)
What compiles and what doesn't
As at 28th of July, 2012, the following packages require GCC to compile on a x86 Gentoo build, Intel CPU, in a VirtualBox VM.
/etc/portage/package.env=app-admin/gam-server-0.1.10-r1 gcc
=app-crypt/gnupg-2.0.19 gcc
=dev-db/mysql-5.1.62-r1 gcc
=dev-libs/elfutils-0.149 gcc
=dev-libs/klibc-1.5.20 gcc
=dev-libs/libffi-3.0.11 gcc
=dev-libs/libgcrypt-1.5.0-r2 gcc
=dev-libs/mpfr-3.0.1_p4 gcc
=dev-libs/nettle-2.4 gcc
=dev-libs/openssl-1.0.0j gcc
=kde-misc/polkit-kde-kcmodules-0.98_pre20101127 gcc
=media-libs/gst-plugins-base-0.10.35 gcc
=media-libs/gstreamer-0.10.35 gcc
=media-libs/libv4l-0.8.8 gcc
=media-libs/mesa-7.11.2 gcc
=media-video/mjpegtools-2.0.0-r1 gcc
=sys-apps/busybox-1.20.1 gcc
=sys-apps/tcp-wrappers-7.6-r8 gcc
=sys-apps/which-2.20 gcc
=sys-auth/polkit-kde-agent-0.99.0 gcc
=sys-boot/grub-0.97-r10 gcc
=sys-devel/binutils-2.21.1-r1 gcc
=sys-fs/e2fsprogs-1.42 gcc
=sys-libs/gdbm-1.8.3-r4 gcc
=sys-libs/glibc-2.14.1-r3 gcc
=sys-libs/gpm-1.20.6 gcc
=sys-libs/zlib-1.2.5.1-r2 gcc
=www-client/firefox-10.0.5 gcc
=x11-apps/luit-1.1.1 gcc
=x11-base/xorg-server-1.12.2 gcc
=x11-drivers/xf86-video-vesa-2.3.1 gcc
=x11-libs/qt-core-4.8.2 gcc
=x11-libs/qt-gui-4.8.2 gcc
=x11-libs/qt-opengl-4.8.2 gcc
=x11-libs/qt-svg-4.8.2 gcc
- Lyallp 07:39, 28. Jul. 2012 (UTC)
- It's been 4 years since this was updated. Are these packages still problems? Could we get some testing, please? --Moonchilde (talk) 21:44, 4 July 2016 (UTC)
- I will be happy to provide an updated list soon: Currently I am rebuilding my whole system (--emptytree @world) with clang/llvm and LTO enabled. For those packages that are broken by LTO, I have an env without LTO, and for those who won't compile at all, there's an env for GCC as a failover. This way we'll have a pretty good impression of the current situation. Currently I'm about 1/3 through and it looks promising, e.g. binutils, xorg-server and qt-gui have compiled just fine (including LTO) and are running. -- RustySpoon (talk) 17:20, 5 July 2016 (UTC)
- Great, I'm interested in your results. It would be nice to include a table with packages that need no-lto environments in the wiki article. What are your clang settings at the moment? -- Moonchilde (talk) 02:45, 6 July 2016 (UTC)
- I'm going with -flto in make.conf and the nolto-env just adds another -fno-lto. The gcc-env then changes CC and CXX back to the GCC values. -- RustySpoon (talk) 04:51, 6 July 2016 (UTC)
- Ah yes, I was using that a bit to learn how to set up Clang but it was too out of date and I couldn't get it to work. Some of the packages on his list compile fine now, for example nvidia-drivers compiles with Clang using -flto and does not create a bad binary anymore. I'll update the Talk page with a list of stuff once I get my system fully updated. *Edit* Never mind, nvidia-drivers is being forced into using GCC. I'll still follow up with what I find. -- Moonchilde (talk) 06:07, 13 July 2016 (UTC)
- Excellent. I emerged -e system last night. Out of 275 packages, 4 required GCC and about 80 or so required -fno-lto. Working on world now. -- Moonchilde (talk) 07:24, 14 July 2016 (UTC)
- I've done it, here's the packages that requires GCC to be compiled.
- FILE
/etc/portage/package.env/gcc# All bug numbers are from Gentoo Bugzilla. dev-java/icedtea gcc # unknown argument: -fpch-deps dev-libs/elfutils gcc # needs compiler w/ GNU99 support # see bug 451986 <=media-libs/mesa-12.0.1 gcc # patch not in upstream # see bug 587442 <=sys-boot/efibootmgr-0.12 gcc # Will be fixed next release <=sys-libs/efivar-0.23 gcc # Will be fixed next release # see bug 587094 sys-libs/glibc gcc # gcc extensions doesn't compile # see bug 502476 sys-kernel/gentoo-sources gcc # REMOVE ONLY IF THE KERNEL CAN BE # COMPILED USING CLANG x11-drivers/nvidia-drivers gcc app-emulation/virtualbox-modules gcc app-emulation/virtualbox gcc media-sound/audacity gcc # Undefined reference? sys-block/thin-provisioning-tools gcc # Reference to validator is # ambiguous dev-util/systemtap gcc # function definition is not # allowed dev-lang/spidermonkey gcc app-text/aspell gcc # error everywhere sci-libs/fftw gcc # don't know how to enable OpenMP # see bug 587248
- And here's the packages that requires
no-lto
- And here's the packages that requires
- FILE
/etc/portage/package.env/lto<=dev-libs/libaio-0.3.110 no-lto <=net-libs/libasyncns-0.8-r3 no-lto <=media-libs/libuninameslist-20091231 no-lto <=dev-libs/rlog-1.4 no-lto <=sys-apps/sandbox-2.10-r1 no-lto <=dev-lang/spidermonkey-1.8.5-r4 no-lto <=dev-libs/pth-2.0.7-r3 no-lto <=media-libs/giflib-4.1.6-r3 no-lto <=media-libs/libid3tag-0.15.1b-r4 no-lto <=media-libs/stimg-0.1.0 no-lto <=sys-libs/db-6.0.35 no-lto # Requires bfd too <=dev-qt/qtscript-4.8.6-r2 no-lto <=net-ftp/vsftpd-3.0.2-r1 no-lto <=dev-python/numpy-1.10.4 no-lto <=sys-fs/fuse-2.9.7 no-lto <=sys-devel/gettext-0.19.7 no-lto <=dev-libs/popt-1.16-r2 no-lto <=sys-libs/binutils-libs-2.25.1-r2 no-lto <=sys-libs/efivar-0.21 no-lto <=dev-libs/elfutils-0.166 no-lto <=dev-libs/libgcrypt-1.6.5 no-lto <=media-libs/alsa-lib-1.0.29 no-lto <=media-libs/giblib-1.2.4 no-lto <=media-libs/x264-0.0.20140308 no-lto <=dev-libs/libIDL-0.8.14 no-lto <=sys-apps/texinfo-6.1 no-lto <=dev-lang/ruby-2.1.9 no-lto <=app-text/rarian-0.8.1-r2 no-lto <=net-print/cups-2.1.3-r1 no-lto <=x11-libs/vte-0.28.2-r207 no-lto <=dev-libs/libunique-1.1.6-r1 no-lto <=x11-libs/gtksourceview-3.18.2 no-lto <=dev-python/pygtksourceview-2.10.1-r1 no-lto <=sci-libs/fftw-3.3.4 no-lto <=media-libs/mesa-12.0.1 no-lto <=x11-drivers/nvidia-drivers-367.27 no-lto <=mail-client/thunderbird-38.8.0 no-lto <=media-video/ffmpeg-2.8.7 no-lto <=x11-libs/wxGTK-2.8.12.1-r1 no-lto <=media-sound/audacity-2.0.5 no-lto <=app-emulation/virtualbox-5.1.0 no-lto <=app-shells/zsh-5.2 no-lto # Successfully compiled # but failed ALL tests
- It has to be, since I'm using it to set the linker to BFD on a per package basis. Where did you read it isn't? If you run clang -fuse-ld=bfd you will get a message asking for a command. If you run a non-existent flag, it will error out telling you that flag doesn't exist. I think some packages turn off the flag which is why we'll see the "unused flag" warning in some of our logs. FWIW, sys-fs/fuse failed to compile with both LTO and no LTO when using Gold, but compiled when I added the -fuse-ld=bfd flag while using Clang. I haven't had a chance yet, but I'm going to update the article for it since this is a step that we need.
- The only thing is, I've seen some packages I swore I compiled with LTO using Gold via binutils-config that failed to compiled using -fuse-ld=gold. I'll do some testing of each method and see if it really is some packages ignoring the -fuse-ld flag. I was going to forsake the binutils-config step and see if we can keep it simpler by using -fuse-ld= instead, but if we get more compiles using binutils then that would be the superior option. We still need environments going back to bfd since a very small handful of packages fail to build when using Gold. The other thing to test is if we need to pass along -fuse-ld to the linker, in which case since we're doing this via compiler we need to have -Wl,-fuse-ld=bfd/gold in our LDFLAGS. -- Moonchilde (talk) 11:52, 15 July 2016 (UTC)
- I found a great example we can use. Cairo. During error logs it ignores the -fuse-ld=bfd via this error: #clang-3.8: warning: argument unused during compilation: '-fuse-ld=bfd'. If it fails to compile with Gold but compiles with BFD, then we'll need to bring this up to the Gold maintainers since there is no reason Gold shouldn't link the files. If the system is using Gold via the binutils-config --linker command, and Cairo is ignoring the flag, then we'll need an update for that. Or, we'll need to get Gold to work right and figure out why one linker works over the other. -- Moonchilde (talk) 12:02, 15 July 2016 (UTC)
- Hi guys, thanks for your efforts to get things working. Just to note, the wiki is a place for documentation, not really a place for development. The forums would probably be a better place to collaborate about this. I'll close this discussion now. Feel free to update the main article if you find things the community should know! --Maffblaster (talk) 17:58, 23 March 2017 (UTC)
Gentoo bugs for compilation failures
- General tracker bug for Gentoo FreeBSD bug #417789
- dev-libs/libffi-3.0.11 bug #417179
- dev-libs/openssl-1.0.0j bug #417795
- sys-libs/ncurses-5.9-r2 bug #417763
The bugs I listed above have patches that fix build failures.
- Gentoofan 12:42, 11. Jun. 2012 (UTC)
- There's nothing to discuss about the wiki article here. Bug reports and issues with packages should be reported on our Bugzilla. Package specific workarounds (that will not be fixed by the Gentoo package maintainer) can be described in a Troubleshooting section. Closing this 'discussion'. --Maffblaster (talk) 17:12, 23 March 2017 (UTC)
is clang-ar still needed?
In my llvm/clang installation I found /usr/bin/llvm-ar (describes itself as "OVERVIEW: LLVM Archiver (llvm-ar)"). I've replaced my AR make.conf variable with it, and it seems to work?
1. Is the wrapper you proposed still needed?
2. If not, and I can use the llvm-ar, I shouldn't need to pass parameters to it (it doesn't work if I set it to "AR=/usr/bin/llvm-ar --plugin /usr/lib/llvm/LLVMgold.so"), right?
3. Besides I found other llvm-* executables like llvm-link, llvm-as, and llvm-ranlib. Should I change LD, AS and RANLIB variable (respectively) in my make.conf?
- Spitfire 23:02, 5. Mar. 2015
The library path for the gold plugin is outdated on the article. LLVMgold.so resides in /usr/lib64/LLVMgold.so so it wouldn't be surprising if things have changed. For example, I can't get games-emulation/higan to compile based on the clang-lto.conf example in the article using clang-3.8.0. I can if I don't use the lto example. However, changing it to the following allows higan to compile and install.
/etc/portage/env/clang-ltoEnvironment override named clang-ltoCC="clang"
CXX="clang++"
CFLAGS="${CFLAGS} -O4"
CXXFLAGS="${CXXFLAGS} -O4"
LDFLAGS="${LDFLAGS} -O4"
AR="/usr/bin/llvm-ar"
RANLIB="/usr/bin/llvm-ranlib"
NM="/usr/bin/llvm-nm"
This should be invoking lto via the -O4 flag and I'm not using the clang-ar wrapper posted in the article. I don't know how to see if it's actually linking though. Thoughts?
- Moonchilde July 3, 2016
- After more testing, should we actually be using -flto? When a package would fail to compile, there were several errors about -O4 being the same as -O3 for clang and defaulting to -O3. According to the documentation for clang 3.9 via http://llvm.org/docs/GoldPlugin.html it states you should pass the -flto flag clang which will in turn pass the -plugin flag to ld. As of clang 3.8 and binutils 2.25.1-r1, after setting my ld to ld.gold system wide using the command binutils-config --linker ld.gold the below setup is also successfully compiling for me. Using the default ld.bfd packages fail to compile from the compiler not working.
- FILE
/etc/portage/env/clang-ltoEnvironment override named clang-ltoCC="clang" CXX="clang++" CFLAGS="${CFLAGS} -flto" CXXFLAGS="${CXXFLAGS} -flto" LDFLAGS="${LDFLAGS} -flto"
- Any way to test if this is actually correct? Thank you.
- --Moonchilde (talk) 08:59, 4 July 2016 (UTC)
- The article is terribly outdated. You are probably right, pure -flto should be the way to go. Feel free to update the snippet with your last one, and remove the wrapper. Michał Górny (talk) 17:22, 4 July 2016 (UTC)
- Please look over the new edit. This is my first time working on the wiki, and I want to make sure everything is correct. One thing I'm not sure about is passing optimizations to the linker. I left that statement there from the prior revision. This page is the only page I'm seeing making that statement. LLVM's documentation doesn't seem to have it, but I've only done a quick google at the moment. The only thing it really mentions about linking is clang passing the -plugin flag to the linker, nothing about optimizations. FWIW, setting LDFLAGS to include ${CFLAGS} which in my personal make.conf has -march=native -O3 -pipe and -flto, and things are still compiling ok. I've also removed any LDFLAG modifications and left it at default and it still manages to compile. -flto is definitely being accepted by clang since if it wasn't a legitimate flag, clang would simply not work and report an error about an incorrect flag being used. I also testing throwing on a non-existent flag to the linker and it fails compiling. Does this mean we really should be using optimizations in the linking stage? Should it be set to the same as CFLAGS? Thank you.--Moonchilde (talk) 00:04, 5 July 2016 (UTC)
Earlier I was thinking about how clang -flto passes along the -plugin option to the linker automatically, so I wondered about ar and nm. According to the LLVM Gold documentation, both ar and nm can accept the -plugin flag. However, neither of them have a -plugin option if you check the arguments you can pass along to them, but they have --plugin. So I tried adding the --plugin option to my AR lines to see what would happen. sys-libs/timezone-data failed because it didn't have an argument prior to --plugin, which makes sense based on how we used to have to set up the old clang-ar wrapper. Then I started to wonder about llvm-ar, which also doesn't have a -plugin option or --plugin option, so how does it know to use the LLVMgold.so plugin?
Apparently, neither ar or llvm-ar need them. Without passing any arguments along, timezone-data compiled correctly and linked all the files using both ar and llvm-ar.
/var/log/portage/sys-libs:timezone-data-2016f:20160708-201906.logclang -o zdump -flto -march=native -O3 -pipe -std=gnu99 -flto -march=native -O3 -pipe -Wl,-O1 -Wl,--as-needed zdump.o localtime.o asctime.o
x86_64-pc-linux-gnu-ar ru libtz.a localtime.o asctime.o difftime.o
x86_64-pc-linux-gnu-ar: creating libtz.a
x86_64-pc-linux-gnu-ranlib libtz.a
1 warning generated.
clang -o zic -flto -march=native -O3 -pipe -std=gnu99 -flto -march=native -O3 -pipe -Wl,-O1 -Wl,--as-needed zic.o
/var/log/portage/sys-libs:timezone-data-2016f:20160708-202924.logclang -o zdump -flto -march=native -O3 -pipe -std=gnu99 -flto -march=native -O3 -pipe -Wl,-O1 -Wl,--as-needed zdump.o localtime.o asctime.o
llvm-ar ru libtz.a localtime.o asctime.o difftime.o
llvm-ar: creating libtz.a
x86_64-pc-linux-gnu-ranlib libtz.a
1 warning generated.
clang -o zic -flto -march=native -O3 -pipe -std=gnu99 -flto -march=native -O3 -pipe -Wl,-O1 -Wl,--as-needed zic.o
As you can see, both of them do the same thing. Feel free to use either llvm-ar or ar with clang. We still need to have ld.gold set as the default linker. This settles my previous question of whether ar and nm were functioning properly. I've learned a lot working on this! -- Moonchilde (talk) 20:48, 8 July 2016 (UTC)
Is FEATURES="test" necessary?
How accurate is it? I'm getting failures with packages no matter which compiler I use, such as binutils. It fails regardless. Does test really work?
- I must say it's pretty accurate (at least with app-shells/zsh). As because zsh failed the tests and can't be run properly when LTO is on. binutils compiled fine here.
- Anyway, sign your comments, please. Konimex (talk) 07:14, 12 August 2016 (UTC)
- The forums or IRC are the place to ask this question. After you get an answer, if there's an issue in the documentation, then change it. --Maffblaster (talk) 17:16, 23 March 2017 (UTC)
LLD
This might be slightly off-topic, but still seemed to be the best place. If you know something where it's better located, please let me know.
As can be seen in the release notes for LLVM 3.9 its linker LLD has reached some important milestone. It would be nice to have an ebuild for it. Before I start trying to do this (would be my first time) I'd like to check if someone else is probably already working on it, or there are important reasons not to do it. Maybe someone could even help me when I run into issues ;-)
Any ideas/input on this?
- RustySpoon 13:25, 04 September 2016 (UTC)
- This is probably the perfect place for it. Clang still requires linking, so if we want to build a system utilizing the entire LLVM backend, which is what Clang is built on, then it's a pretty important piece of the puzzle. I don't think the linker is ready, otherwise flto wouldn't require Gold or LD64 from Xcode8 to link on Linux. Or, perhaps it's ready for linking, but not doing LTO. I guess we could ask the LLVM developers and clarify?
- - Moonchilde (talk) 06:12, 12 September 2016 (UTC)
- I just built chromium 54 with clang and lld 3.9.0 using thin-lto, so that shouldn't be much of a problem there. Check out [1], it is a project to build a GNU-free gentoo toolchain, including the whole LLVM stack. He's pretty far (in fact already having a new profile being reviewed for a complete clang based system) and I've brought up the lld idea in a comment in this post.
- - RustySpoon 06:54, 12 September 2016 (UTC)
- I've sent zlei some emails here and there, lol. Good person to chat with. I'm not sure, but you might be able to define LD in make.conf with the LD="lld" flag. Testing. Well, doesn't seem to work. I would propose an eselect to replace binutil-config --linker. That would make the most sense. Any chance you could paste your ebuild here?
- Ninja-edit. LD="gitgud" does work, and libedit just failed because command "gitgud" doesn't exist.
- FILE
/var/tmp/portage/portage/dev-libs/libedit-20130712.3.1/temp/build.log/var/tmp/portage/portage/dev-libs/libedit-20130712.3.1/temp/environment: line 1174: gitgud: command not found
- - Moonchilde (talk) 09:18, 12 September 2016 (UTC)
- binutils-config doesn't work for lld of course. But it's possible to imitate its behavior:
- Simply remove /usr/x86_64-pc-linux-gnu/binutils-bin/2.26.1/ld (its a symlink) and ln -s /usr/bin/ld.lld /usr/x86_64-pc-linux-gnu/binutils-bin/2.26.1/ld
- Good thing: If a package breaks, just use binutils-config --linker ld.gold to reset it to gold. I re-repaired the ebuild. Just add CMAKE_BUILD_TYPE=Release in the src_configure() section before the mycmakeargs stuff. It'll build just fine. Then tweak the symlink and fire away.
- - RustySpoon 10:07, 12 September 2016 (UTC)
- Going to test some more, but if it's really as easy as setting LD="/usr/bin/ld.gold" or LD="/usr/bin/lld" in make.conf then who even cares? Then you can do a per package basis using an environment that overrides LD in make.conf with LD="/usr/bin/ld.bfd" if we need to. No need for symlinks or eselect tools, a simple text editor will work. Since we're already doing that for packages that require GCC, might as well do it for those that will require ld.bfd if we run across any packages that do. I just tested this against timezone-data and ld.gold linked it up since that's what was defined in make.conf.
- How do I find your ebuild?
- Moonchilde (talk) 10:28, 12 September 2016 (UTC)
- Now that llvm version 4.0.0 has added to Portage, I don't think there's reason to discuss further. Closing discussion. --Maffblaster (talk) 18:01, 23 March 2017 (UTC)
thinlto
I just went about and tried thinlto - a few corrections to the suggestion are needed to make it work. First, specifying -O2 is pointless for LDFLAGS. The documentation of ld states clearly that the flag is just binary, any numeric value other than 0 enables them all. Second, some packages do not pass CFLAGS to LDFLAGS. In such cases (for example qtcore), linking will fail as -flto=thin needs to be passed. My conf file for packages using thinlto looks as follows:
/etc/portage/env/clang-lto.confEnvironment override named clang-ltoCXX="clang++"
CFLAGS="${CFLAGS} -flto=thin"
CXXFLAGS="${CXXFLAGS} -flto=thin"
LDFLAGS="${LDFLAGS} -flto=thin"
- Hi there, could you please sign your post next time? Anyway, the Wiki is a little out of date and I need to do a lot of work on it. Unfortunately I have not had the time since I've been doing a lot of package testing (hours and hours of compiling... hopefully one day I'll get to actually use my computer for fun again) using Clang + LLD. Nearly all my time on my PC is doing that and not editing a Wiki since I'd like to be as concise as possible for what works and what doesn't, and this means setting things up system wide. FWIW, you don't need to set -flto=thin in LDFLAGS. -Wl,-O2 is actually relevant if you use LLD as it affects linking speed. GNU linker is binary as you stated, but LLD functions a little different. It doesn't hurt to have -Wl,-O2 since for GNU anything higher than 1 will simply optimize the same as if it was -O1. I've compiled qtcore without flto=thin in LDFLAGS and about 850+ packages on my system that don't require GCC because of GCC specific code or forcing GNU linkers. If it helps, this is what my LDFLAGS looks like at the moment.
- FILE
/etc/portage/make.confLDFLAGS="-Wl,-O2 -Wl,--as-needed -Wl,--gc-sections -march=native -O3 -fuse-ld=lld -rtlib=compiler-rt -stdlib=libc++ -Wl,-lto-O3 -Wl,--build-id -Wl,--error-limit=0 -Wl,--icf=all -Wl,--thinlto-jobs=8 -Wl,--threads"
- Because LLD has -lto-O<opt-level> it makes -O3 being set in LDFLAGS redundant and frankly not needed since that tells the linker to optimize during link time at whatever level you specify. BFD (which now accepts plugins, so Clang can pass along -flto to it) and Gold will be a little different since they don't have that option.
- Moonchilde (talk) 06:21, 18 August 2017 (UTC)
- If Moonchilde hasn't got around to it yet, it's not gonna happen. --Davidbryant (talk) 19:24, 9 August 2020 (UTC)
gentoo-clang overlay
I have created gentoo-clang overlay available via layman: gentoo-clang (hosted here). Maybe it would be useful to add it to wiki page, cos as for the moment it simplifies use of clang as system-wide compiler?
-fPIE isn't working well
Following this wiki to the letter makes a lot of mess with packages that would fail compliation, and then suggest that they need to be compiled with -fPIC and not -fPIE. Changing only PIE to PIC makes for a much smoother run.
Differences between GCC and Clang
[User:TakodaNotDakota] wrote "The -m and related flags are supposed to work identically, but Clang may not know about certain options. There are also Clang-only options not known by GCC." Could some specific use cases when using the -m flag be detailed, please? I don't think most users are going to run into problems with it or bother defining -m based flags. Simply noting there are compiler specific flags and behavior seems a little obvious, considering they're different toolchains. I did update some old info and expand on the original written text with links to sources including source code and tried to keep it a bit more relevant to users coming from GCC to Clang, such as glibc being an issue first and foremost.
Unhappy-Ending (talk) 01:50, 27 October 2023 (UTC)
Should there be advanced examples for the gcc env?
It seems out of scope for the page to expand on how to modify env files for gcc. Even so the non-lto example is redundant as its trying to do the same thing as the initial example. I think the whole section should be axed.
Parona (talk) 23:43, 31 December 2023 (UTC)
emerge error with llvm target AArch64
Fg I've temporally reverted your chance as we aren't sure what this fix is for or if is still required. Would you mind explaining the need in a little more detail for us please so we can add it back if needed.
Thanks for all the work you do in the wiki normally as well!
Referring to https://forums.gentoo.org/viewtopic-p-8694149.html, append
*/* -llvm_targets_AArch64 to /etc/portage/profile/package.use.force
- Thanks Immolo! This was around a week ago. Sorry if this is hard to reproduce, but this can happen for Clang or LLVM dependencies. Emerging postgresql, ruby, mesa or other Clang packages for systems without can cause it. I don't compile for ARM so excluding is okay for me right now as it was the only blocker. I'm not sure if it's rare so deleting the edit might be better. Fg (talk) 01:15, 11 May 2024 (UTC)
- Thanks for getting back, I've tried reproducing and can't hit it so I think you hit something else and this just fixed the problem for you. Based on that I'm going to leave the revert in place.