Rahul, please take a look at this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/a369ad483fdab6aa50e38635d80f7e540d3ffc08

commit a369ad483fdab6aa50e38635d80f7e540d3ffc08
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Mar 02 06:38:39 2016

wget: disable clang syntax checking

The build fails w/max_align_t namespace clashes.

BUG= chromium:591285 , chromium:591290 
TEST=precq passes

Change-Id: I6e80cab81c8d351ca89b2cb95f5dc010f7e1006c
Reviewed-on: https://chromium-review.googlesource.com/329533
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Yunlian Jiang <yunlian@chromium.org>

[add] https://crrev.com/a369ad483fdab6aa50e38635d80f7e540d3ffc08/chromeos/config/env/net-misc/wget

can we just fix this?

Here's what I have so far:

wget uses lib/stddef.in.h to generate lib/stddef.h during configure/build. This header file defines some standard stuff (including max_align_t) if the system libraries didn't define them.

For gcc only builds, it defines max_align_t. The builds works fine.

For clang only builds, it detects the predefined max_align_t from clang/3.8.0/include/__stddef_max_align_t.h and the builds work fine.

The problem arises only when running gcc with -clang-syntax. Configure enables the definition of max_align_t in lib/stddef.h since gcc needs it, but when clang reads the header file, it complains about re-definition because it already has it defined.

One solution I can think of is to guard the definition of max_align_t in lib/stddef.h by the macro __CLANG_MAX_ALIGN_T_DEFINED (which is defined in clang/3.8.0/include/__stddef_max_align_t.h). I've tested this patch for wget-1.17.1 and confirmed that it works. Does applying this patch in the wget ebuild look like a good approach?

--- lib/stddef.in.h
+++ lib/stddef.in.h
@@ -94,6 +94,7 @@
 # else
 #  define _GL_STDDEF_ALIGNAS(type) /* */
 # endif
+# ifndef __CLANG_MAX_ALIGN_T_DEFINED
 typedef union
 {
   char *__p _GL_STDDEF_ALIGNAS (char *);
@@ -101,6 +102,7 @@ typedef union
   long double __ld _GL_STDDEF_ALIGNAS (long double);
   long int __i _GL_STDDEF_ALIGNAS (long int);
 } max_align_t;
+# endif
 #endif
 
 #  endif /* _@GUARD_PREFIX@_STDDEF_H */

lib/stddef.in.h is a gnulib file, so you'll want to check/coordinate with the gnulib project:
https://www.gnu.org/software/gnulib/

especially because the way gnulib works is that its source gets copied into many many GNU projects directly from their git.

if there's already a fix in gnulib git, it'll be easy to add to the wget ebuild.

what was the resolution for this bug.

The issue exists only when we use gcc for builds but use clang for syntax checking. The current workaround is to disable -clang-syntax for this ebuild.

The problem will be resolved automatically when we switch to using llvm for builds as well, so it should not be blocking 537368.

@rahul, can this be closed now? 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/6ccdd6e4306e553387a42a2801333e0a001c169b

commit 6ccdd6e4306e553387a42a2801333e0a001c169b
Author: Rahul Chaudhry <rahulchaudhry@chromium.org>
Date: Fri Sep 29 03:51:03 2017

net-misc/wget: revert 'disable clang syntax checking'.

The original issue with clang-syntax only happens when the package was
built with gcc. Now that the package has switched to build with clang,
we don't need to disable clang-syntax.

BUG= chromium:591290 
TEST='sudo emerge net-misc/wget' works.

Change-Id: If8cccf661f78ea8ed034e9e4633730f3b26e1ae5
Reviewed-on: https://chromium-review.googlesource.com/689861
Commit-Ready: Rahul Chaudhry <rahulchaudhry@chromium.org>
Tested-by: Rahul Chaudhry <rahulchaudhry@chromium.org>
Reviewed-by: Caroline Tice <cmtice@chromium.org>

[delete] https://crrev.com/cff73f567dd0d253c55ac7ade4782e93c8cdf074/chromeos/config/env/net-misc/wget