Fix builds on FreeBSD, OpenBSD, and NetBSD#114233
Fix builds on FreeBSD, OpenBSD, and NetBSD#114233Kaleb-Reid wants to merge 1 commit intogodotengine:masterfrom
Conversation
7ea07f8 to
c36d3f7
Compare
caeded2 to
59b9ca1
Compare
59b9ca1 to
8a72cb1
Compare
92cbbcd to
fb38fe1
Compare
fb38fe1 to
c6e9277
Compare
830e724 to
65af78a
Compare
|
I'm moving the changes to the wrappers to a new pr, this pr still fixes compilation but optional runtime libraries will not be found on OpenBSD or NetBSD. |
|
@DeanLemans I'm essentially just waiting for reviews. |
abda78e to
d04ff90
Compare
bd8906b to
2677f9a
Compare
67e0b1e to
06745cc
Compare
| int count = swapctl(SWAP_NSWAP, 0, 0); | ||
| if (count > 0) { | ||
| swapent swap_info[count]; | ||
| swapent *swap_info = (swapent *)memalloc(count * sizeof(swapent)); |
There was a problem hiding this comment.
It seems fine, but not sure why having it on stack was an issue, was it too large because of PATH_MAX?
There was a problem hiding this comment.
@bruvzg This triggered a compiler warning for having a variable length array, which in dev mode aborted compilation.
| //////////////////////////////////////////////////////////////////////////////// | ||
| /// OpenBSD Platform | ||
| //////////////////////////////////////////////////////////////////////////////// | ||
|
|
||
| #if defined (__OPENBSD__) |
There was a problem hiding this comment.
Did you look into contributing this upstream to Embree?
There was a problem hiding this comment.
@akien-mga I didn't bother to because the OpenBSD implementations of the functions are just dummy implementations. Until now so were the NetBSD ones, but I just changed them to be the same as the Linux implementations as NetBSD seems to support the same interfaces as Linux in this case.
| return "gcc" in os.path.basename(env["CC"]) or ( | ||
| sys.platform.startswith("netbsd") and os.path.basename(env["CC"] == "cc") | ||
| ) | ||
|
|
||
|
|
||
| def using_clang(env): | ||
| return "clang" in os.path.basename(env["CC"]) | ||
| return "clang" in os.path.basename(env["CC"]) or ( | ||
| (sys.platform.startswith("freebsd") or sys.platform.startswith("openbsd")) | ||
| and os.path.basename(env["CC"]) == "cc" | ||
| ) |
There was a problem hiding this comment.
That sounds quite error prone if either of these *BSD platforms change their default cc compiler in the future. They don't provide gcc and clang binaries?
It's been working in the past without requiring those changes, I wonder why this is needed now.
There was a problem hiding this comment.
@akien-mga I may be able to revert the NetBSD one, but the other two are necessary because it was causing builds done with the default system compiler (cc which is a copy of clang) to not be forced as llvm builds which made certain compiler flags not be applied, causing issues such as failing when compiling in dev mode due to missing flags to ignore warnings as well as not adding the clang-specific linker flags for statically linking libc++. If instead we check CXX, I believe only OpenBSD would need a workaround because it's default is c++ which is a copy of clang++.
There was a problem hiding this comment.
I've reverted the modification to using_gcc but kept the one to using_clang
|
I just noticed there's a FreeBSD ports update for 4.6.1. Sharing here just in case you haven't seen it. |
I was able to compile from scratch on FreeBSD 15.0 / 13.5, OpenBSD 7.8 / 7.7, and NetBSD 10.1 without disabling anything using this pr.
I briefly ran the editor on OpenBSD, created a new project, and add a couple nodes in 3D. I currently do not have access to a FreeBSD or NetBSD machine with a display out so I have only briefly tested them in headless mode.
Basically what I've done when compiling under bsd:
HAVE_SECURE_GETENVfor openxr.input-event-codes.hcan be removed because it is not available on NetBSD.size_twithuint64_tin the wayland implementation instead of adding alongconstructor toVariantdue to OpenBSD definingsize_taslong. The two wayland files are the only ones in the project with this problem so it seems overkill to changeVariantto fix the problem.Also the issue in #101588 (comment) where the editor would not compile is due to the process memory limit being relatively low in OpenBSD by default (1.5GB for users with the
staffclass). I also had this failure around the same part, but if you raise the limit (e.g.ulimit -d 10000000), then you can compile fine.Fixes #55192
Fixes #92130
Fixes #110606
Supersedes #101588