Skip to content
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

OpenBSD: fix integration and broken specs #15118

Merged

Conversation

ysbaddaden
Copy link
Contributor

Follow up of #15115 but for OpenBSD.

Fixes compatibility with OpenBSD 7.4 that enforced indirect branch tracking by default but we're not compatible yet (see #13665), so we must disable it.

With this patch I can run the std specs, except for the SSL specs because of openssl/libressl mess, as well as the compiler specs, except for the interpreter specs that regularly crash with SIGABRT (may help to debug issues in the interpreter).

Note: the segfault handler is broken on OpenBSD and processes eventually crash with SIGILL after receiving SIGSEGV.

@ysbaddaden ysbaddaden added kind:bug A bug in the code. Does not apply to documentation, specs, etc. platform:bsd labels Oct 22, 2024
Comment on lines +504 to +508
if program.has_flag?("freebsd") || program.has_flag?("openbsd")
# pkgs are installed to usr/local/lib but it's not in LIBRARY_PATH by
# default; we declare it to ease linking on these platforms:
link_flags += " -L/usr/local/lib"
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought: I was wondering about the motivation for this. Seems like the default configuration is just sub-optimal. Apparently compilers in ports do add the folder, only the system compiler does not (https://wiki.freebsd.org/WarnerLosh/UsrLocal).
Maybe we should add some reference for justification here? Not sure if that link would do, it was just the first relevant result on Google.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you build from ports, then a port can patch it in, yeah, but when you compile or cross compile your own crystal binary then it breaks and you must think to export LIBRARY_PATH.

It ain't much, but that's nice. We did it before, but that got lost and I couldn't find why.

expect_raises(Socket::Addrinfo::Error, "Hostname lookup for badhostname failed: ") do
Socket::Addrinfo.resolve("badhostname", 80, type: Socket::Type::DGRAM)
expect_raises(Socket::Addrinfo::Error, "Hostname lookup for badhostname.unknown failed: ") do
Socket::Addrinfo.resolve("badhostname.unknown", 80, type: Socket::Type::DGRAM)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I didn't mean to push this fix in this PR but to make it it's own PR.

The problem here is that within my vagrant/libvirt VM resolving a hostname without an extension leads to 30 seconds (freeds, netbsd) to 2.5 minutes (openbsd) time to fail to resolve the name 😲

Using a domain with an extension, however, fails to resolve immediately 🤷

OpenBSD 7.4+ enforces Indirect Branch Tracking but we're not yet
compatible in Crystal, so we disable the feature for the time being.
This results in always reporting:

```
bin/crystal[204]: Brewfile: not found
```
@straight-shoota straight-shoota added this to the 1.15.0 milestone Oct 24, 2024
@straight-shoota straight-shoota merged commit 8a96e33 into crystal-lang:master Oct 25, 2024
68 checks passed
@ysbaddaden ysbaddaden deleted the fix/openbsd-integration branch October 25, 2024 08:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bug A bug in the code. Does not apply to documentation, specs, etc. platform:bsd
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants