Bug 1158594 - clang++ cannot link libstdc++ (without gcc-c++)
Summary: clang++ cannot link libstdc++ (without gcc-c++)
Keywords:
Status: CLOSED DUPLICATE of bug 1021645
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-29 17:09 UTC by Rex Dieter
Modified: 2015-05-31 03:35 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-31 03:35:02 UTC
Type: Bug


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.