On 4/29/14, Markus Trippelsdorf wrote:> On 2014.04.29 at 12:16 +0200, Tuncer Ayaz wrote: > > 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? > > No. During bootstrap you'll have to patch libstdc++. You can build > and use libc++ after that.Okay, but isn't that impractical for repeated builds? If this is the official way to build llvm on a system with gcc-4.9 as the host CXX, it's probably best to document it.
On 4/29/14, Tuncer Ayaz wrote:> On 4/29/14, Markus Trippelsdorf wrote: > > On 2014.04.29 at 12:16 +0200, Tuncer Ayaz wrote: > > > 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? > > > > No. During bootstrap you'll have to patch libstdc++. You can build > > and use libc++ after that. > > Okay, but isn't that impractical for repeated builds? > > If this is the official way to build llvm on a system with gcc-4.9 > as the host CXX, it's probably best to document it.Bump. Is it really unsupported to build llvm from scratch with gcc 4.9 and libstdc++ 4.9? Should I file a bugzilla ticket instead?
On 02/05/2014 20:45, Tuncer Ayaz wrote:> Bump. > > Is it really unsupported to build llvm from scratch with gcc 4.9 and > libstdc++ 4.9? Should I file a bugzilla ticket instead?Obviously LLVM/clang should compile out of the box using the current stable GCC version, and failure to do so would be a potential release blocker. Please file a PR Tom, do you know about this issue? Alp. -- http://www.nuanti.com the browser experts