Created attachment 1127662 [details] Sample C++ program Description of problem: For the current Fedora development tree, the attached sample C++ code fails to get compiled by clang++: $ clang++ -o test test.C : CommandLine Error: Option 'track-memory' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Version-Release number of selected component (if applicable): clang-3.7.1-4.fc24 How reproducible: Always Steps to Reproduce: 1. Run 'clang++ -o test test.C'. Actual results: : CommandLine Error: Option 'track-memory' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Expected results: Compilation completes as expected. Additional info: - Code was still compiled correctly by clang only a fews days ago. - Code is being compiled successfully by c++ (GCC) 6.0.0 20160212 (Red Hat 6.0.0-0.11).
To be more specific: the error is merely triggered by executing 'clang'.
*** Bug 1309535 has been marked as a duplicate of this bug. ***
clang is basically unusable in rawhide at the moment.
I think the clang is linked incorrectly. It looks like the problem appeared quickly after switching to single libLLVM.so. I don't get the reason for this change from the commit message. http://pkgs.fedoraproject.org/cgit/rpms/llvm.git/commit/?id=933aa4780e9fc790fee3c4bcbdedfcd04025bd71 And there is also a second commit I would blame. I don't know why would the clang required llvm-static. My initial clang package built witout it and worked for me. http://pkgs.fedoraproject.org/cgit/rpms/llvm.git/commit/?id=7a851779bb53767ed8e7ca3ac4e3e6280d969d1c
Neither of those commits should cause it though. The single LLVM.so is because the split set is broken, and upstream isn't interested in fixing it. They stated we shouldn't be using that configuration. So I went to the recommended upstream configuration and rebuilt things, I'm still not sure why this happens though. The llvm-static is just due to stupid llvm cmake scripts looking for some stuff, try building without llvm-static involved and see what falls out.
Dave, thank you for explanation. I'll try to find some time to take a look at this then.
I think I've pushed the fix to the clang repo, I can't build at the moment as koji is down.
*** Bug 1311489 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
okay I think this is fixed in clang-3.8.0-0.3.fc24 reopen if not.
This is still an issue on s390(x), but it seems they haven't updated clang yet (3.7.1-4.fc24 gets installed in the buildroot).
I'm trying to get a working clang3.7 package built (see bug #1420512) but am running into this issue as well. I applied some changes from the clang-3.8.0-0.3 package but that did not appear to be sufficient. Was it something in 3.8.0 that fixed it?
Nevermind, I sorted it out. Wrong version of shared libraries being loaded.