Bug 1158594

Summary: clang++ cannot link libstdc++ (without gcc-c++)
Product: [Fedora] Fedora Reporter: Rex Dieter <rdieter>
Component: llvmAssignee: 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: 22CC: 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:

Description Rex Dieter 2014-10-29 17:09:25 UTC
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.

Comment 1 Jakub Jelinek 2014-10-29 17:31:58 UTC
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.

Comment 2 Rex Dieter 2014-10-29 18:41:07 UTC
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).

Comment 3 Adam Jackson 2014-11-19 16:28:23 UTC
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.

Comment 4 Jaroslav Reznik 2015-03-03 16:27:05 UTC
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

Comment 5 Zbigniew Jędrzejewski-Szmek 2015-05-31 03:35:02 UTC

*** This bug has been marked as a duplicate of bug 1021645 ***