Bug 1139077

Once this patch is applied, is there a way to select the default headers and runtime when devtoolset is installed?

Upstream's idea is to select the latest and greatest available at runtime, so there isn't really a default. The patch just makes clang find gccs in devtoolset locations too. clang 3.4.2 supports gcc up to 4.9.x which will be in devtoolset-3.

*** Bug 1161334 has been marked as a duplicate of this bug. ***

llvm-3.4.2-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/llvm-3.4.2-2.el6

Package llvm-3.4.2-2.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing llvm-3.4.2-2.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4086/llvm-3.4.2-2.el6
then log in and leave karma (feedback).

llvm-3.4.2-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

This change has caused problems with some users because devtoolset pulls some trickery with glibc and such and it now had to be used when building with clang. I have added a patch from Gregor Jasny that allows the devtoolset to be used by setting the CLANG_DTS_LIST environment variable to a space separated list of the desired devtoolsets in /opt/rh. This allows devtoolset to be installed but not used when the existing patch always required it to be used when it was installed.

He also pointed out that devtoolset can be used through the --gcc-toolchain flag. For example:
clang --gcc-toolchain=/opt/rh/devtoolset-3/root/usr -v

This updated version with runtime selection of devtoolset is being built now and will be available in the testing repo soon.

"-gcc-toolchain" could always be used, and it can still be used like in 

$ clang -gcc-toolchain /usr -v

to avoid any devtoolset. It's just a question of what should be the default. Going for the latest gcc available is how upstream does it, why invent more elaborate trickery for selection, which also has to be communicated to users? It would be easier to just drop this thing altogether.

Besides, are there any examples for this "trickery with glibc and such"? I didn't quite get it.

I have heard complaints from a few users since this change was added and it seems that the issue is when using libraries that were built with stock gcc 4.4. I didn't dig into the issue in detail to find what the cause was, but my original desire was that the use of devtoolset could be turned on and off (see comment #1). The previous solution of just adding all the devtoolsets to the search list didn't support that and this one does. I agree that it's a bit annoying to have to "enable" the use of devtoolset but I think that not tying the users hands to always using it is an important use case to continue supporting and well worth the inconvenience.

Also, this method supports any new devtoolsets that are added and not just the list that was in the original patch. For example, if/when a devtoolset 2.1 or 3.1 was added the previous solution would require an updated build to use them. This solution has the advantage that it "just works" any time a new version of the devtoolset is added.

Then why not simply remove *all* devtoolset patches? "-gcc-toolchain" is clumsy, but does the job. My patch was only about the *default*. A new method for selection isn't necessary, one was built-in from the very beginning. It works now and did so before.

(Newer devtoolsets don't have a minor number anymore, and -3 is the last one that works with clang-3.4.2 which is only compatible with gcc up to 4.9.x. The list can therefore be considered complete.)

llvm-3.4.2-4.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/llvm-3.4.2-4.el6

Just for the fun of it: a lot of people don't use RH's 'scl' command but environment modules instead. But ok, I'm out. You broke more than you fixed.

llvm-3.4.2-4.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/llvm-3.4.2-4.el7

I'm sorry that you feel that way. I understand your concern and the logic that you used when creating the original patch was sound and matches with upstream mentality, but the fact is that users need a way to enable/disable the use of devtoolset with clang. For better or worse, the SCL mechanism is RedHat's way to do that, so this change makes use of that mechanism so that clang's use of devtoolset is more inline with how devtoolset itself is used.

llvm-3.4.2-5.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/llvm-3.4.2-5.el7

llvm-3.4.2-5.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

llvm-3.4.2-4.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.