Latest stable (buildroot-2018.08.2) also fails with same error

```
...
mv -f .deps/sjlj.Tpo .deps/sjlj.Plo
In file included from /home/user/buildroot-2018.08.2/output/host/powerpc-buildroot-linux-gnu/sysroot/usr/include/stdio.h:862:0,
                 from ../../../libitm/util.cc:27:
/home/user/buildroot-2018.08.2/output/host/powerpc-buildroot-linux-gnu/sysroot/usr/include/bits/stdio2.h: In function ‘int sprintf(char*, const char*, ...)’:
/home/user/buildroot-2018.08.2/output/host/powerpc-buildroot-linux-gnu/sysroot/usr/include/bits/stdio2.h:34:43: error: invalid use of ‘__builtin_va_arg_pack ()’
       __bos (__s), __fmt, __va_arg_pack ());
                                           ^
/home/user/buildroot-2018.08.2/output/host/powerpc-buildroot-linux-gnu/sysroot/usr/include/bits/stdio2.h: In function ‘int snprintf(char*, size_t, const char*, ...)’:
/home/user/buildroot-2018.08.2/output/host/powerpc-buildroot-linux-gnu/sysroot/usr/include/bits/stdio2.h:65:44: error: invalid use of ‘__builtin_va_arg_pack ()’
        __bos (__s), __fmt, __va_arg_pack ());
                                            ^
Makefile:517: recipe for target 'util.lo' failed
make[5]: *** [util.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
```

Thanks for your bug report. Could you try without the following options:

BR2_SSP_REGULAR=y
BR2_RELRO_PARTIAL=y
BR2_FORTIFY_SOURCE_1=y

and see if the problem still appears ? If it does not appear, enabling those options one by one to see which one breaks the build would be useful.

Removing the 3 options (SSP, RELO and FORTIFY) produce a working toolchain.

Enabling Fortify_Source_1 produces the error I originally posted.

Enabling Relo and SSP do not generate errors.

Let me know if I can do additional debugging.

Hi,

I'm able to reproduce this issue with gcc5 but not with gcc6.
Any reason to keep this specific version ? 

gcc5 is not maintained by upstream and we already use the latest version, I'm not sure it would be easy/safe to backport an upstream patch.

Best regards,
Romain

I have not had any problems thus far with gcc6, so I personally don't have a problem with dropping gcc5 support but I would suggest making Fortify_Source require gcc>=6 for ppc iff there are no plans for dropping gcc5 for other arches.

If it would help I can volunteer to run a matrix of PPC big endian builds to see which of them fail.

At some point us PowerPC guys won't have much left but unsupported tools unfortunately.

(In reply to goldstar611 from comment #5)
Hi,

Are you using libitm ?
If not, you can workaround this issue by disabling libitm with:
HOST_GCC_COMMON_CONF_OPTS += --disable-libitm

This issue is trigged with gcc5 + libitm and Fortify_Source.
I'm able to reproduce it on x86_64.

Unfortunately, we don't test the toolchain build with all possible options.
For example, Fortify_Source option is not enabled while building pre-built Bootlin toolchains [1]. That's why this issue is only discovered now...
This is something that can be improved on our side.

Any additional testing are welcome, feel free to run a matrix of PPC big endian you are interested in and report to us or upstream if it works or not.

About gcc5, at some point it will be removed from Buildroot. I can't say when.

[1] https://toolchains.bootlin.com

Best regards,
Romain

Hi,

I found an upstream bug report about this issue [1].
With this patch [2] applied the build succeed.

I can't say why upstream didn't backport this patch on gcc5 stable branch.
So, I'm ok to disable fortify_source for gcc5.

Best regards,
Romain

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=61164
[2] https://github.com/gcc-mirror/gcc/commit/55f12fce4ccf77513644a247f9c401a5b1fa2402

Romain: what do you suggest for this bug? Should we exclude gcc < 6 from using fortify source ? Should we backport a gcc fix ?

(In reply to Thomas Petazzoni from comment #8)
Hi Thomas,

The issue is fixed in Buildroot by this patch [1] that disable BR2_FORTIFY_SOURCE_{1,2} for gcc < 6 (for internal toolchain only).
Upstream didn't answer my question if it's safe or not to backport this patch to earlier version of gcc [2].

So, this bug is fixed for 2018.11.

[1] https://git.buildroot.net/buildroot/commit/?id=a75ee0e8124023185f4a05e95b2fcd29fa9449d8
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=61164

Best regards,
Romain

Fixed by https://git.buildroot.net/buildroot/commit/?id=a75ee0e8124023185f4a05e95b2fcd29fa9449d8.