-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build fails on OpenBSD 7.2 #1111
Comments
This is a problem internal to the OpenBSD standard library, since it tries to use a function that it does not define. (To be precise, their implementation of a certain function in I don't know what C++ library FreeBSD nor OpenBSD uses, so I can't troubleshoot this myself. Any links would be appreciated. |
If I understand correctly OpenBSD is hiding features that are not posix ( For the rgbds side perhaps the define should not be set except for platforms its required? Otherwise maybe avoiding non-posix features such as There are a few other places this issue seems to have occurred before. |
This does look similar to at least the latter issue, and also feels like a repeat of #789, where non-POSIX but C11 features were withheld, until an Omitting Considering that fact, I am tempted to say the issue in on BSD and not us; however, discussion on #789 also started like that but became more nuanced. Thus, I think a bug report should be opened (by you or by us, whichever you think is better), and a solution agreed upon. The solution (on their side) that I see right now, would be making |
That is intentional behavior. I believe it might required by the standard too. However, this particular error is due to a bug in the OpenBSD headers. It should not be worked around in RGBDS. |
Well, we had the same argument in #789: we want POSIX APIs and C11 ones, when the POSIX standard more or less says "the following APIs shall be provided, and nothing else". Here, we want POSIX APIs and C++ ones... but the C++ implementation relies on some non-POSIX APIs, which sounds like a clash between user-space and library-space? Augh.
If I may, what kind of fix is planned? |
Yes, exposing POSIX and C11 APIs at the same time is inherently contradictory. The correct thing for RGBDS to do in that situation is to declare the needed C11 prototypes and symbols manually. The implementation (i.e., the operating system) does not have that option except by willfully flouting the standard.
As I said, this is a bug in the headers (which are part of LLVM’s libc++—OpenBSD happens to expose it because the error is in a codepath only taken by systems that omit xlocale, which is nonstandard). It will affect everything that includes iostream after declaring
There’s a patch floating around. I’ll do what I can to get it committed. |
That's a stance I could never fully understand: extensions to the standards exist, so why couldn't the C11 features be treated as an extension to the POSIX standard?
That seems incorrect, as declaring functions ourselves implies that suitable symbols will exist at link time, but the actual implementation may decide instead to have another link name and to alias it via a macro or another mechanism. (I have things like this in mind, for example.) |
To reply to a comment from the old thread:
I’m aware of a conflicting behavior. Here is a C program: #include <assert.h>
int
main()
{
int static_assert;
return 0;
}
Compilers happily expose most things by default, or allow you to request them by declaring a nonstandard symbol in the namespace reserved to the implementation, because understandably most people don’t know or care about the finer details of C revisions. But if you explicitly request the behavior of a formal standard by defining the symbol specifically provided for the purpose, the compiler expects that you want that standard, and properly exposes only what that standard provides.
Because they would clobber the namespace reserved to users, and that’s expressly prohibited. Of course, all bets are off if the implementation chooses to come up with an option like
Yes, I suppose you would have to provide your own function implementations as well. Still, though, you could |
- yank _POSIX_C_SOURCE because it breaks the build See also: gbdev/rgbds#1091 gbdev/rgbds#1111 Reported by: danfe, gerald
Do we even still need |
A further comment in that thread notes that this is only an implementation detail of libstdc++, whose C++ headers define I'm not sure that's portable to other C++ libraries? |
If it's portable enough to build on Windows, macOS, Ubuntu/Mint/Elementary/etc, Arch/Manjaro/etc, and even OpenBSD/FreeBSD, I'd say that's fine. Worth trying out? |
After setting up an OpenBSD 7.5 VM (and Googling for some advice re: a "wdc_atapi_start: not ready" error), I've found that this issue still occurs with clang 16.0.6: |
See the discussion in google/flatbuffers#6205 and WebAssembly/wabt#1360 for what to potentially do about this. (Conditionally define |
This seems potentially related to: #1091
This will fix the problem, but I think there may be a better way, and someone more familiar with the codebase may have a better solution:
Full build output:
The text was updated successfully, but these errors were encountered: