Configure: don't try to be clever when configuring afalgeng

[rossburton]

If the afalgeng is enabled then Configure tries to be clever but fails, by only
actually building afalgeng if it isn't being cross-compiled and if the current
kernel is 4.1+.

This means that everyone cross compiling, or whose builder machines are running
older kernels (not uncommon for build farms), can't enable afalgeng.

Instead remove the cleverness and simply enable/disable as requested.

Fixes #7687

[richsalz]

+1 to this!

[levitte]

Do we want to consider the possibility to enable it automatically if neither disable-afalgeng nor enable-afalgeng have been given?

The procedure to do so is quite simple, have it disabled by default ($disabled{afalgeng} == 'default'), and if it hasn't been enabled or disabled explicitly (for the latter, $disabled{afalgeng} == 'option'), run the check and modify $disabled{afalgeng} accordingly.

[mattcaswell]

Close/reopen to kick CLA bot.

[kaduk]

Do we want to consider the possibility to enable it automatically if neither disable-afalgeng nor enable-afalgeng have been given?

Is that the sound of a yearning for autoconf that I hear?

[levitte]

Is that the sound of a yearning for autoconf that I hear?

No. The needed config code is already in place, all that's needed is to only run it when no afalgeng option has been given to run it.

[t8m]

As this is mostly removing useless code, we could accept this with CLA: trivial if you put the CLA: trivial on a separate line in the commit message.

[tom-cosgrove-arm]

@t8m ping - Ross has added the "CLA: trivial" line

[openssl-machine]

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

[paulidale]

Would this benefit from a CHANGES.md entry?

[t8m]

Would this benefit from a CHANGES.md entry?

IMO this is fairly marginal thing, so not worth it.

[openssl-machine]

This pull request is ready to merge

[t8m]

I was rethinking this and I've reconsidered my approval. I would be fine with this going into master however in the current form it should not go into stable releases.

@rossburton @tom-cosgrove-arm Are you OK with this just going into the 3.1 release?

[t8m]

If we wanted to put this into released branches we would have to do it the way @levitte proposed above #7688 (comment)

[rossburton]

I'm fine with master only.

[t8m]

Merged to master branch. Thank you for your contribution and patience given this had to wait for so long time.

[rossburton]

No problem, thanks!

[mattcaswell]

This PR seems to have broken something:

https://github.com/openssl/openssl/actions/runs/2022523976

[rossburton]

How did the CI for the PR work but then explode the moment it was merged! 😭

[rossburton]

As that is quite a dramatic explosion, can it be reverted whilst I debug?

[t8m]

How did the CI for the PR work but then explode the moment it was merged!

Because we do not actually try to run the tests on cross compiled targets in the pull request CI. Running them via qemu is too slow. We run them only once the patches are merged.

IMO we just need to disable the afalgeng in our CI for the cross compile targets.

[t8m]

As that is quite a dramatic explosion, can it be reverted whilst I debug?

I've merged disablement of the failing test in CI. If you can find out why the test fails under qemu, it would be nice. I suppose the qemu does not translate the syscall number properly or something.