Conversation
|
I've got this one in #859 |
c2b65b8 to
7961fea
Compare
|
Thanks for taking the -lm part in #859. I have force-pushed this branch |
| return "netbsd" | ||
| if os_name.find("dragonfly") != -1: | ||
| # The JVM reports "dragonflybsd"; uname and GOOS say "dragonfly". | ||
| return "dragonfly" |
There was a problem hiding this comment.
i think it would be nicer to have bsd in the name still, but if that causes other issues it's probably fine not to
| "%{cpu}": get_cpu_value(repository_ctx), | ||
| }) | ||
| elif cpu_value == "freebsd" or cpu_value == "openbsd": | ||
| elif cpu_value in ["freebsd", "openbsd"] and _use_legacy_bsd_toolchain(repository_ctx): |
There was a problem hiding this comment.
| elif cpu_value in ["freebsd", "openbsd"] and _use_legacy_bsd_toolchain(repository_ctx): | |
| elif cpu_value in ("freebsd", "openbsd") and _use_legacy_bsd_toolchain(repository_ctx): |
| "%{cpu}": get_cpu_value(repository_ctx), | ||
| }) | ||
| elif cpu_value == "freebsd" or cpu_value == "openbsd": | ||
| elif cpu_value in ["freebsd", "openbsd"] and _use_legacy_bsd_toolchain(repository_ctx): |
There was a problem hiding this comment.
should this contain netbsd and others too? or are we just making those to never use the legacy toolchain?
| fail("FreeBSD / OpenBSD should use bsd_cc_toolchain_config.bzl") | ||
|
|
||
| cc = _find_generic(repository_ctx, "gcc", "CC", overridden_tools) | ||
| cc = _find_generic(repository_ctx, "gcc", "CC", overridden_tools, warn = True, silent = True) |
There was a problem hiding this comment.
should we be worried that this logic would select gcc on bsd if they had that installed alongside the default? maybe instead we should not make the logic so generic and just only look for cc on bsd based on cpu_value?
Really? I tried it with a simple piece of code, but Click to expand the log
Update: In the Bazel link action, The compiler driver therefore emits -lpthread inside that --as-needed scope, and OpenBSD's linker drops it. The resulting binary has So I don't think As an additional note, some OpenBSD ports disable Update 2: I tried disabling Quick patch |
7961fea to
d2d6a5f
Compare
|
@c2qd The objdump was the thing -- my evidence was the wrong kind. I had -z origin is back too. The static toolchain carried it as part of Measured on OpenBSD 7.9 in CI this time rather than by hand, since both are Neither check stops at "it ran". Your log has the binary printing Hello, world |
|
@zakinko I tried it locally, and it looks like all the issues I pointed out have been fixed. Thanks for the work~ |
|
Took the tuple, and narrowed the compiler search the way you suggest. FreeBSD and OpenBSD have no gcc in base, so the only gcc on PATH is one CC and overridden_tools still take precedence, since _find_generic Each job prints toolchain_identifier, compiler, target_libc, the driver, netbsd and dragonfly are left out of the legacy branch on purpose, and it finds neither /usr/bin/clang nor /usr/bin/dwp, gets "ld.gold: error: Three of those four carry the base compiler's version, as does If what you want is symmetry, I would go the other way: once this has On the name, I would lean towards keeping dragonfly. uname -s prints |
|
Thank you for trying it on a real OpenBSD -- that was the check I could not |
FreeBSD and OpenBSD have been routed to a static toolchain since 2016, one that writes in the compiler path, the builtin include directories and the link libraries, while every other Unix gets those probed. NetBSD and DragonFly never got a name at all and fell through to the autoconfigured path by accident, which works apart from the toolchain being called "k8". Run the autoconfiguration on all four. Four things it did not know how to do there: - Find the C driver, since the BSDs install it as cc and a gcc-first search would prefer one from ports or pkgsrc over the compiler the system was built with. - Name the BSD libcs for //cc/libc, which stopped at NetBSD. - Set DF_ORIGIN. Bazel puts $ORIGIN in the RPATH it generates and OpenBSD's ld.so only expands it when that flag is set; glibc and musl expand it either way, so the need is invisible on Linux. The static toolchain carried -z origin (bazelbuild#855, for bazelbuild#854) and the autoconfigured one did not. - Leave the C++ standard libraries outside --as-needed on OpenBSD. The driver expands -lstdc++ to -lc++ -lc++abi -lpthread there, and libpthread is only reached through the other two, so wrapping the expansion drops it and the binary dies at startup on undefined pthread_* symbols (bazelbuild#857). I had claimed the link libraries needed no change, on the strength of cc -### showing the driver substituting the platform's C++ runtime for -lstdc++. That was the wrong measurement: cc -### prints what the driver passes to the linker, not what survives the link. @c2qd caught it with an objdump of the NEEDED entries and a binary that failed to start. The static toolchain stays behind BAZEL_USE_LEGACY_BSD_TOOLCHAIN=1, the way the legacy macOS toolchain does. It is offered only for FreeBSD and OpenBSD, which are the two BUILD.static.bsd describes.
d2d6a5f to
c0b63cb
Compare
3 participants
This replaces the -lm change, which #859 has since covered -- thanks for
taking it.
FreeBSD and OpenBSD have been routed to a static toolchain since 2016, one
that writes in the compiler path, the builtin include directories and the
link libraries, while every other Unix gets those probed. NetBSD and
DragonFly never got a name and fell through to the autoconfigured path by
accident, which works apart from the toolchain being called "k8". Building
Bazel on any of the four has meant passing things in from outside: the
include directories on the static side are those of the release they were
taken from, and the link libraries are #857 and #161.
This runs the autoconfiguration on all four. It needed two things it did
not know: to find the C driver when there is no gcc, since the BSDs that
ship clang have only cc; and to name the BSD libcs for //cc/libc, which
stopped at NetBSD. The link libraries did not need a change, which I had
not expected: clang on FreeBSD and OpenBSD maps -lstdc++ to the platform's
C++ runtime, -lc++ on FreeBSD and -lc++ -lc++abi -lpthread on OpenBSD
(cc -### shows the substitution), so the autoconfigured default holds. The
static toolchain wrote -lc++ in directly, which the driver leaves alone,
and that is what #857 ran into. The static toolchain stays behind
BAZEL_USE_LEGACY_BSD_TOOLCHAIN=1, the way the legacy macOS toolchain does.
Measured by building Bazel from source (948b8c70) with rules_cc overridden
to this branch and nothing passed in for the toolchain -- no CC, no -lm,
no -std, no link libraries:
Each resulting bazel then ran a genrule in a fresh workspace. Two flags
were still passed, neither about the toolchain: --copt=-include
sys/cdefs.h, because protobuf #defines _POSIX_C_SOURCE in a source file
and hides isascii from libc++'s ; and --features=-layering_check
on the clang BSDs, because the autoconfigured toolchain gives clang a
module map, the check becomes active where the static toolchain had none,
and grpc's wait_for_single_owner.h does not declare its absl dependency.
Users on FreeBSD and OpenBSD will see layering_check start to apply, the
same as on Linux with clang.
The builds used a platforms with the NetBSD and DragonFly host detection
from bazelbuild/platforms#142 and #143 applied; I have not tried without.