Bug 1158594
| Summary: | clang++ cannot link libstdc++ (without gcc-c++) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rex Dieter <rdieter> |
| Component: | llvm | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | ajax, asn, bos, dmalcolm, jakub, jv+fedora, law, petersen, scottt.tw, tomspur, zbyszek |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-05-31 03:35:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
libstdc++.so is intentionally on certain architectures part of gcc-c++, as we don't want those linker scripts or symlinks in /usr/lib{,64} - which libstdc++ and other library to link depends on the gcc version.
Furthermore, gcc uses different multilib directory naming schemes in directories owned by gcc (there it e.g. on x86_64 uses . for 64-bit and 32/ for 32-bit), compared to OS multilib naming scheme (../lib64 for 64-bit, . (== ../lib) for 32-bit, and as libstdc++-devel.i686 needs to be usable by both gcc-c++.x86_64 and gcc-c++.i686, it really can't install files in compiler target dependent directories.
sparc/ppc do things slightly differently, because there the target name between -m32 and -m64 is the same, so extra tweaks are needed for that.
Anyway, if clang++ wants to link against a particular version of libstdc++, best would be if it would package in clang/llvm owned directories a symlink or linker script that would make it work. Not a bug on the gcc side.
I disagree that it's not possible to fix this amicably in libstc++, but fair enough. Reassigning to llvm(clang), to choose to include an appropriate symlink or linker script as suggested (or not). Reassign to nobody@. I have no time and no interest in working on clang, and the only reason it's even in the llvm package is because it can't be built any other way. If anyone wishes to volunteer for comaintainer with a focus on clang, please let me know (preferably with direct email, if it's in bz I'll likely miss the request), I'll be happy to hook you up. This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 *** This bug has been marked as a duplicate of bug 1021645 *** |
Had a user on #fedora-devel irc today wondering any clang++ was failing to compile a simple c++ test-case: /usr/bin/ld: cannot find -lstdc++ I couldn't reproduce on my f20 i686 box, but further investigation found that it had to do with libstdc++.so symlink existing (or not). Turns out the symlink is in libstdc++-devel on i686, but on x86_64 it's in gcc-c++ packaging. I tried and failed to find the rationale behind this (it's been this way going back at least as far back as fedora 8). anyway, it at least fails the smell test to require clang (and it's c++ compiler) to include a dependency on gcc-c++ (instead of just libstdc++-devel). So here we are, with a request to include libstdc++-.so symlink in libstdc++-devel unconditionally, ie, remove this conditional from libstdc++-devel %files: %ifnarch sparcv9 ppc %{multilib_64_archs} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libstdc++.so %endif (for the %{multilib_64_archs} case at least), and related bits accordingly.