On 4/29/14, Markus Trippelsdorf wrote:> On 2014.04.29 at 11:04 +0200, Tuncer Ayaz wrote:
> > On 4/27/14, Markus Trippelsdorf wrote:
> > > On 2014.04.27 at 16:18 +0200, Tuncer Ayaz wrote:
> > > > Using gcc 4.9 to build the llvm 3.4 branch fails with the
> > > > following error:
> > > >
> > > > llvm[1]: Compiling APFloat.cpp for Release build
> > > > [...]
> > > > /usr/[...]/include/c++/4.9.0/cstddef:51:11:
> > > > error: no member named 'max_align_t' in the global
namespace
> > > > using ::max_align_t;
> > > > ~~^
> > > >
> > > > gcc 4.8.2's caused no such issue, so it must be a change
in
> > > > 4.9.0/cstddef.
> > > >
> > > > To be clear, I have no idea who's at fault (gcc 4.9.0
header
> > > > or llvm sources), assuming any code is to be blamed (at
all).
> > >
> > > You can simply wrap it with #ifndef:
> > >
> > > namespace std
> > > {
> > > // We handle size_t, ptrdiff_t, and nullptr_t in c++config.h.
> > > #ifndef __clang__
> > > using ::max_align_t;
> > > #endif
> > > }
> > > #endif
> >
> > Yeah, but are you sure the bug is in libstdc++ and has to be fixed
> > in gcc upstream? I mean, would it be the wrong choice to include a
> > fix in the next llvm 3.4 release?
>
> One could argue that nothing needs to fixed. The libstdc++
> developers don't care very much about clang interoperability. The
> clang developers don't care about libstdc++ issues.
> Just use libc++ with clang and you're set.
Maybe I wasn't clear, but the issue is building (bootstrapping) llvm
on a system with gcc-4.9 as the host compiler. Are you suggesting that
to build llvm with libstdc++-4.9 I should first build libc++ with
gcc-4.9, and use that lib (instead) when building llvm? Is that even
possible?