getrandom() backwards compatibility shim

[0xEAB]

People have been unhappy about the new getrandom() dependency.
Check out the sibling PR dlang/phobos#10741 for further details.

[dlang-bot]

Thanks for your pull request, @0xEAB!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "stable + dmd#21158"

[dkorpel]

Thanks for looking into solutions for this.

Before we get something like this in, can we please consider all other options that don't involve new build configurations? These tend to stack up into an unmaintainable mess for Martin (or another unfortunate soul) to thanklessly untangle later.

Asking users to build their own version of the library and the compiler is bad UX, especially since the linker error they see doesn't hint to the existence of this flag. And the change didn't just break usage of std.random.unpredictableSeed, it reportedly broke an empty D program. I'd be pretty annoyed if I had to jump through hoops just because a module I don't even use was changed.

• Can we make the symbol link on an as-needed basis, perhaps by making the functions that depend on getrandom templates?
• Can we define the getrandom stub as a weak symbol so it automatically links it when the (hopefully strong) GLibC symbol is missing?
• Can we use late binding (dlopen / dlsym) to try to link getrandom at runtime?

[0xEAB]

Thanks for looking into solutions for this.

Actually… Thanks for reviewing this.

Before we get something like this in, can we please consider all other options that don't involve new build configurations?

Sure thing! :)
So, I did not open this pair of PRs to get them merged as-is. I rather did provide them as a proof-of-concept to support my argument that we don’t have to revert the Phobos PR that adds the getrandom() dependency.

These tend to stack up into an unmaintainable mess for Martin (or another unfortunate soul) to thanklessly untangle later.

The more sustainable, the better.
Needless to say, there isn’t much that’s easier to show one’s gratefulness towards them than just not making their work harder. That said, thanks Dennis, Martin and Iain! (And everyone else involved!)

[0xEAB]

_{Sorry for the additional noise, but I’m already phrasing and typing my messages for the second time. I accidentally lost my first draft by hitting the back button on my mouse.}

And the change didn't just break usage of std.random.unpredictableSeed, it reportedly broke an empty D program.

As we are dealing with a linker error, that’s is a given, ain’t it?

I'd be pretty annoyed if I had to jump through hoops just because a module I don't even use was changed.

Fair enough. You either didn’t jump through the sys upgrade hoop either or are using a very LTS distro to avoid additional sys upgrade hoop. Or in other words, this inconvenience affects the exact person that would be annoyed the most by running into it. Yeah, it’s not exactly nice.

So let me clarify this… I didn’t write this patch this way because I thought it was the most ideal solution but because it was the most straightforward one. And especially because submitting a PR would hopefully show that I do care about the issue at hand.

[0xEAB]

Can we make the symbol link on an as-needed basis, perhaps by making the functions that depend on getrandom templates?

Fair question. I’m afraid that this change would bubble up a bit and could do so a bit too much.

Luckily, most of std.random is a template already, but then there’s other modules that import it — though many of them seem to be limited to unittests. At least, randomUUID() would also need to be turned into a template (the non-templated overload obviously).

Can we define the getrandom stub as a weak symbol so it automatically links it when the (hopefully strong) GLibC symbol is missing?

We could. At least to my understanding of the matter.
But I’m not confident that my emulator is a good enough replacement to slip unsuspecting builds into their executable.

However, if someone were to write a shim that did actually perform the proper getrandom syscall, I’d approve of that immediately. (Just that I’ve pointed it out, this approach comes at the cost of failing at runtime on 10+ year old Linux kernels that don’t implement said syscall.)

Can we use late binding (dlopen / dlsym) to try to link getrandom at runtime?

• Yes, we can. AFAIK we already do so for libcurl.
• But people aren’t always happy about it. std.net.curl doesn't work with -static phobos#10629

[ibuclaw]

Curl is third party/optional however.

This is about different abi versions of a core library dependency.

If there's a version it should be opt-in rather than opt-out.

version = HAVE_GETRANDOM;

[0xEAB]

Thanks for all the feedback, everyone!
I’m currently experimenting with an alternative approach. Will keep you updated.