Link to 32-bit inode symbols on FreeBSD

[valpackett]

This fixes building on FreeBSD >= 12 without introducing OS version conditions.

---

Since dlang/dmd#8567 is still in endless bikeshedding mode, let's just do this already.

[dlang-bot]

Thanks for your pull request and interest in making D better, @myfreeweb! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

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 fetch digger
dub run digger -- build "master + druntime#2668"

[thewilsonator]

Seems fine to me cc @jmdavis

[jmdavis]

Then how would we move to using the correct version of these functions on FreeBSD 12 down the line? This just seems like a temporary workaround. Long term, we need to be using the FreeBSD 12 versions of these symbols on FreeBSD 12, not forcing the FreeBSD 11 versions, and as far as I can tell, that means that we need to version the bindings.

If we do this, what's the plan for making it so that we can then link against the correct FreeBSD 12 symbols later?

[jmdavis]

Also, this approach introduces the problem that any attempt to use the druntime structs with any other C libraries on FreeBSD 12 won't work, because the structs will be wrong.

[valpackett]

how would we move to using the correct version of these functions on FreeBSD 12 down the line?

Exactly like how you would without this patch — the existing declarations would be versioned to <=11, and the >=12 case would be either unversioned symbols or symbols with the new versions (FBSD_1.5 in most cases).

Note that linking to versioned symbols would allow targeting <=11 when working on >=12.

This is what Rust does (though they only added the 12 ABI for testing right now, it's not shipped at all).

any other C libraries

Do they even exist? Has anyone ever actually made a third party libc that works on FreeBSD?

[valpackett]

(Actually, the libc is the public API of FreeBSD, which is why alternative libcs were never encouraged or supported.)

[jmdavis]

Exactly like how you would without this patch — the existing declarations would be versioned to <=11, and the >=12 case would be either unversioned symbols or symbols with the new versions (FBSD_1.5 in most cases).

Okay. So, basically, long term, this doesn't fix anything, but it shouldn't get in the way of anything either. It just lets us build what are essentially FreeBSD 11 binaries on FreeBSD 12 for the time being.

Do they even exist? Has anyone ever actually made a third party libc that works on FreeBSD?

I wasn't talking about alternate libcs. I was talking about other C libraries that might use any of the definitions from libc in their own APIs. I don't know how big an issue that is in practice, though right now, nothing works on FreeBSD 12 anyway. So, while this could have problems, it's better than where we are at present.

[valpackett]

other C libraries that might use any of the definitions from libc in their own APIs

Ah. There's absolutely nothing wrong with using the 1.0 (<=11, 32-bit inode) symbols and 1.5 (>=12, 64-bit inode) symbols in the same program!

The only way to screw something up is passing statfs etc. structs between druntime and random external C libs.

Hopefully bindings to lib APIs expecting these structs won't reuse the druntime definitions of them. (Automatically generated bindings probably won't?)