Bug 13543

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 => Cauldron
Assignee: bugsquad => tmb
Whiteboard: (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 => RESOLVED
Resolution: (none) => FIXED
Depends on: (none) => 13811