Re: [patch core/stackprotector] stackprotector: Fix build whencompiler lacks support

[Sam Ravnborg]

Hi all.

> > 
> >   config CC_SUPPORTS_STACKPROTECTOR_STRONG
> >       bool
> >       option exec="$CC -fstack-protector-strong -c empty.c"
> > 
> > or something like that. No?
> 
> This is an implementation detail, but the original patch expected the
> result to be 'y' or 'n' (or empty=='n') on stdout. That way, it could
> also be used to fill-in config options that are strings, or ints. Hence
> the use of a script.
> 
> But H. Peter suggested it should only return a boolean, which seems
> entirely reasonable, given the purpose of this. In this case, using 'y'
> or 'n' from stdout, or 0 or !0 from the exit code are equally easy.
> 
> Also, using a single shell script allows to fix/enhance all of those
> calls in a single place, and avoids duplicating all the check logic in
> every tests (eg. who is going to create empty.c in your example? Clean
> up the output file?). And since kconfig is run from the top-level of the
> Linux source tree (even for out-of-tree builds), we can safely use a
> path relative to that to call our script(s).
> 
> I'll wait a bit until the end of the holiday season before I poke Sam
> again on this.

The thinking behind the exec option was that it should return a string,
and then the content of the string were parsed depending on the type used in
the kconfig language.
So for a bool "y" and "n" would be recognized.
For tristate in adddition "m" would be recognized.
For int we should be able to parse numbers.
And string would be string.

An if an exec'ed command gave e return code != 0 then this should result in a warning,
so user is told that the attempt to execute /bin/some_thing_random failed.
Otherwise we would end in situations were this would be difficult to debug.

I have no time to actually implement the above proposal - sorry!
But things are busy at my day-time job etc.
So I hope someone can step in and help here.

PS. I have suffered from a faulty linux box + change of mail provider.
    And in the end I deleted all mails from the last three months.
    This was much quicker than to actually read them :-)

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/