Description of problem: trying to compile something with clang that includes cxxabi.h header fails see this thread http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-February/019909.html for details. What I did as a workaround when building my own package was: ln -s /usr/lib/gcc/x86_64-mageia-linux-gnu/4.8.2/include/cxxabi.h %{buildroot}%{_prefix}/lib/clang/%{version}/include/ ln -s /usr/lib/gcc/x86_64-mageia-linux-gnu/4.8.2/include/bits/ %{buildroot}%{_prefix}/lib/clang/%{version}/include/ - but that of course that would need tweaking for official packages Reproducible: Steps to Reproduce:
Keywords: (none) => TriagedCC: (none) => anssi.hannula, thierry.vignaud, tmb
or just pass an -I/usr/lib/gcc/x86_64-mageia-linux-gnu/4.8.2/include during build of your project
That's not really a solution since that then adds other headers into the searchpath that should not be added/taken from clang instead.
This breaks building firefox-beta too: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20140701064753.tv.valstar.12693/log/firefox-beta-31.0-0.b5.1.mga5/build.0.20140701064804.log
(In reply to Christian Lohmaier from comment #2) > That's not really a solution since that then adds other headers into the > searchpath that should not be added/taken from clang instead. And the presence of those headers break compiling with clang...
Thomas, note that FC have it in /usr/include/c++/4.*/cxxabi.h
Source RPM: llvm => gcc, llvm
The question is: why do we move it away? # Move <cxxabi.h> to compiler-specific directories %if %{build_cxx} mkdir -p $FULLPATH/include/bits/ mv %{buildroot}%{libstdcxx_includedir}/cxxabi.h $FULLPATH/include/ mv %{buildroot}%{libstdcxx_includedir}/%{gcc_target_platform}/bits/cxxabi_tweaks.h $FULLPATH/include/bits/ %endif This came from mdv... We were already doing it when importing packages in SVN: http://svn.mandriva.com/viewvc/packages/cooker/gcc/current/SPECS/gcc.spec?revision=2665&view=markup&pathrev=47181 we were already doing it in 2003: http://vserver.13thfloor.at/Stuff/gcc-3.3.4.spec
Can we stop doing this? We're the only ones to do so and we don't even know why we do it (a 12+ year undocumented hack)
It was already done in libstdc++3.0-devel-3.0.4-2mdk but not in libstdc++3.0-devel-3.0.1-1.1mdk.i586.rpm: http://sophie.zarb.org/distrib/Mandriva/8.2/i586/by-pkgid/b5527029b6c2844eaaf502cba379547d/files http://sophie.zarb.org/rpms/16247870ea0fc18dbc96630f264c172c/files Which points to: * Wed Feb 20 2002 Gwenole Beauchesne <gbeauchesne@mandrakesoft.com> 3.0.4-0.4mdk - Move into gcc3-specific includedir (w/o any explanation) (from http://sophie.zarb.org/distrib/Mandriva/8.2/i586/by-pkgid/b5527029b6c2844eaaf502cba379547d/changelog) So please kill that move
Version: 4 => CauldronAssignee: bugsquad => tmbWhiteboard: (none) => MGA4TOO
Not so fast... It's because we have a setup that supports having several gcc versions installed at the same time... currently we support both gcc3.3 and gcc 4.7 (mga3) / gcc 4.8 (mga4) / 4.9 (cauldron)
And what? FC has it in /usr/include/c++/4.8.3/cxxabi.h What's wrong with that? There's nothing preventing supporting both gcc3.3 & 4.x. And even if it were the case, we could only support having one gcc installed at a time but I dont' think we even have to go there. Note that FC has compat-gcc3* too Do we even have stuff that needs gcc3.3's g++ and not just gcc?
Well, we are not FC. There is nothing that says we have to do everything that FC does, if that would be the case we might as well just run / use FC and be done with it. I actually like to test things before I change stuff...
Sure. But for now we cannot use clang for many c++ software. (eg I cannot compile firefox 31 with either gcc-4.9 or clang). And the default (aka not FC's but upstream's) path is versioned, so how can it break having several compilers installed?
Ok, until I have time to verify all of this, I chose to "fix" it in gcc-4.9.1-0.20140625.2.mga5 currently building with: - ship cxxabi.h and cxxabi_tweaks.h in both upstream default path for clang to work and Mageia specific path to keep backward compatibility (mga#13543)
Thanks I can now compile ff with clang.
Fix in comment 13 pushed to 4 updates_testing as part of an gcc miscompilation update fix: https://bugs.mageia.org/show_bug.cgi?id=13811
Status: NEW => RESOLVEDResolution: (none) => FIXEDDepends on: (none) => 13811