Talk:Clang

From Gentoo Wiki
Jump to: navigation, search
Note
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (~~~~). When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.

"Installation" doesn't actually cover installation

Talk status
This discussion is done.

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

Talk status
This discussion is done.

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

Talk status
This discussion is done.

As at 28th of July, 2012, the following packages require GCC to compile on a x86 Gentoo build, Intel CPU, in a VirtualBox VM.

FILE /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)
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 -O3 -march=native -mtune=native -pipe -flto with -fno-lto and gcc 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.
FILE /etc/portage/package.env/gcc
  1. 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
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

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

Talk status
This discussion is done.

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

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.

FILE /etc/portage/env/clang-ltoEnvironment override named clang-lto
CC="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-lto
CC="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.

FILE /var/log/portage/sys-libs:timezone-data-2016f:20160708-201906.log
clang -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
FILE /var/log/portage/sys-libs:timezone-data-2016f:20160708-202924.log
clang -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?

Talk status
This discussion is done.

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

Talk status
This discussion is done as of Septemper 04, 2016.

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

Talk status
This discussion is still ongoing.

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:

FILE /etc/portage/env/clang-lto.confEnvironment override named clang-lto
CXX="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.conf
LDFLAGS="-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)