Talk:Clang

"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)

Some ideas
Hey! Here are some ideas...


 * 1) 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).
 * 2) 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?"
 * 3) 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)

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.

- 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)


 * I found a more updated list here, it was in December 2015 though. --Konimex (talk) 05:15, 13 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)


 * Anyway, I've done rebuilding all my packages with  with   and   fallbacks. As soon as I'm finishing it up I'll list it here. (Probably tonight) --Konimex (talk) 05:32, 14 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.




 * And here's the packages that requires




 * Also, can anyone tell me how to explicitly set the linker in CFLAGS/CXXFLAGS/LDFLAGS? It seems -fuse-ld=bfd is failed. sys-fs/fuse had to be compiled using bfd and I had to set it maunally. Nevermind, it seems   is not supported by Clang. --Konimex (talk) 16:49, 14 July 2016 (UTC)


 * 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.


 * Here, it seems it was implemented, but it was reverted because it failed some test on Windows. --Konimex (talk) 13:20, 15 July 2016 (UTC)


 * 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)

Gentoo bugs for compilation failures

 * General tracker bug for Gentoo FreeBSD
 * dev-libs/libffi-3.0.11
 * dev-libs/openssl-1.0.0j
 * sys-libs/ncurses-5.9-r2

The bugs I listed above have patches that fix build failures.

- Gentoofan 12:42, 11. Jun. 2012 (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


 * This looks outdated. /usr/lib/llvm no longer exists. The llvm-ar manual doesn't list --plugin as an option so I would assume that's not the way to go. The gcc manual by contrast says that gcc-{ar,nm,etc} are just wrappers. --Ormaaj (talk) 13:08, 13 February 2016 (UTC)

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.

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.




 * 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.

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)

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, 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.




 * - 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)