[Buildroot] [PATCH RFC v1 1/1] gcc: fix problem with detecting SSP under uclibc-ng

Brendan Heading brendanheading at gmail.com
Thu Sep 17 21:22:52 UTC 2015


>> Yeah I knew that exporting it globally was not going to fly - I just
>> submitted it as a starting point for discussion how to solve this.
>
> Sure, no problem with that. It's already much appreciated that you did
> all this investigation.

Thank you for that!

> We are fine with patches being order-dependent. That's fine we have a
> sequence number for all patches in the first place.
>
> So far, the effort to push upstream our gcc patches has been very
> limited. It would be good to push some of them upstream, but in the
> mean time, our stack of gcc patches is not that big, and is not causing
> too many problems when bumping gcc.

Yeah I also get the sense that getting patches upstream in GCC might
be difficult, and when I was googling this I saw other examples of
people running into problems similar to this. I would guess it's
especially unlikely we would get patches into the versions that are in
maintenance mode. We might have more luck with next (ie GCC 6.0).

>> Aside from that .. GCC actually already has a block which checks
>> UCLIBC_HAS_SSP. The problem is that it reaches it only if the glibc
>> version check returns that the version is 2.3 or lower. The fix might
>> simply be to reorder the check.
>
> If it's that simple, then it should be done :) In any case, version
> based tests are often not a good idea, so when uClibc is used, gcc
> should really rely on UCLIBC_HAS_SSP.

Okay, I am now looking at putting together an interim patch set. I
don't think there is any point in trying to submit them into
maintenance releases of the existing versions but it's worth taking a
shot at getting them into -next.

regards

Brendan


More information about the buildroot mailing list