When I was digging into tool version dependency,as you pointed out, gperf is a problem (but seemed one time breakagefor gperf 3.1)flex seemed very stable for a long time.bison seemed a bit problem if old version is used.

But, I did not have enough time to take a closer look.I thought I should respond after I tested more, but I has been pressedby my daily tasks, then time passed...Very sorry.

Today, I just noticed gperf usage got dropped from the kernel.

If CONFIG_MODVERSIONS is enabled,I notice lots of error messages.WARNING: EXPORT symbol "finish_open" [vmlinux] version generationfailed, symbol will not be

So, I think something was broken in scripts/genksyms/.

Of course, it was a trivial conversion, so it should not be hard to fix...

> gperf is clearly written by clowns that don't understand about> compatibility issues - it would have been trivial for them to add some> kind of marker define so that you could test for this directly rather> than depend on some kind of autoconf "try to build and see if it> fails" crap.

One idea may be to process the output of "gperf -v"and embed GPERF_VERSION into the output .c files.

But, if you are unhappy with gperf breakage this time,we can live without gperf.

> It's likely not even any slower, but who the hell knows.. Do we even> care? It's almost certainly faster if you compare to generating that> gperf code.>

For scripts/kconfig/, I think we do not care at allbecause we usually invoke it just once when we configure the build setting.

If we enable CONFIG_MODVERSIONS, scripts/genksyms/ is invokedover and over again.

Sorry, I have not evaluated ifthe perfect hash gives us noticeable advantage or not..