Talk:Clang

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)

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)