Created attachment 454372 [details] build.log The error message is: /mnt/tmpfs/vartmp/portage/sys-libs/libomp-3.9.0/work/openmp-3.9.0.src/runtime/src/kmp_str.c: In function 'void __kmp_str_buf_vprint(kmp_str_buf_t*, const char*, va_list)': /mnt/tmpfs/vartmp/portage/sys-libs/libomp-3.9.0/work/openmp-3.9.0.src/runtime/src/kmp_str.c:211:40: error: '__va_copy' was not declared in this scope __va_copy( _args, args ); // Make copy of args. This happens because the musl libc headers do not define __va_copy. There was no problem with earlier versions of gcc, since they defined __va_copy themselves. The following patch fixes this --- a/runtime/src/kmp_str.c +++ b/runtime/src/kmp_str.c @@ -208,7 +208,7 @@ __kmp_str_buf_vprint( #if ! KMP_OS_WINDOWS va_list _args; - __va_copy( _args, args ); // Make copy of args. + va_copy( _args, args ); // Make copy of args. #define args _args // Substitute args with its copy, _args. #endif // KMP_OS_WINDOWS rc = KMP_VSNPRINTF( buffer->str + buffer->used, free, format, args ); Essentially the same patch is also currently used in the musl overlay. See https://www.gnu.org/s/libc/manual/html_node/Argument-Macros.html for background on the __va_copy macro. In short, it is a GNU extension working around the fact that since va_copy was only added in C99, va_copy will not be defined in strict C90 mode. Since, as visible above, openmp uses C++ style comments, and will therefore not compile in strict C90 mode anyway, the above patch should be safe.
I'd rather have that upstream before we apply it. This is the kind of low-level stuff that I don't feel confident touching.
Created attachment 487508 [details, diff] libomp-3.9.0-gcc6.patch I don't have an musl profile but maybe someone who does can test this patch against sys-libs/libomp-3.9.0 with gcc-6. Backported from https://reviews.llvm.org/D26001 and https://reviews.llvm.org/D35072. Builds fine with gcc-6.3.0 and gcc-5.4.0 on non-musl profile.
I don't see any connection between the patch in commment 2 and this bug. (It doesn't touch the file causing the compilation failure.) The upstream file has changed slightly but still uses __va_copy. Maybe I'll find the time to send the above inline patch upstream, but I would be glad if someone else beat me to it.
(In reply to Felix Janda from comment #3) > I don't see any connection between the patch in commment 2 and this > bug. (It doesn't touch the file causing the compilation failure.) > > The upstream file has changed slightly but still uses __va_copy. > Maybe I'll find the time to send the above inline patch upstream, but > I would be glad if someone else beat me to it. Please disregard the patch. I had been reading build logs from several unrelated bugs at the time and for some reason fixated on PAGE_SIZE being redeclared as the underlying issue. Sorry.
(In reply to Felix Janda from comment #3) > Maybe I'll find the time to send the above inline patch upstream, but > I would be glad if someone else beat me to it. Submitted a bug upstream: https://bugs.llvm.org/show_bug.cgi?id=34040 In a few days I'll try to formally submit the patch for review.
Submitted for upstream review: https://reviews.llvm.org/D36343
(In reply to Peter Levine from comment #6) > Submitted for upstream review: https://reviews.llvm.org/D36343 > This revision is now accepted and ready to land. I don't have a lot of experience with Phabricator. I assume someone with write access will eventually come along and apply it to master branch?
Leave a comment that you don't have commit access and ask nicely that somebody commits it for you. I'd do it but I don't feel confident enough with git-svn that I'm pretty sure I'll do something wrong and lose your attribution ;-).
Fixed upstream: https://reviews.llvm.org/rL311269
Ok. So how far back do you need this backported? 4, upcoming 5.0.0 or 6? Are there any other backports needed?
(In reply to Michał Górny from comment #10) > Ok. So how far back do you need this backported? 4, upcoming 5.0.0 or 6? Are > there any other backports needed? If that's directed at me, for the record I'm just trying to squash gcc-6 bugs. I don't use musl.
Ok, since there was no reply from the OP and musl is not very common, let's assume that upstream fix is good enough and it's going to roll in at its own speed. If you need me to backport it after all, feel free to reopen.
