On 16.06.19 22:25, Jan Beich wrote:
clang-sys didn't support llvm80 when gecko@ switched to it. I'm not
sure myself why but maybe bindgen uses a subset of bindings that're stable
Perhaps, this is something the port's maintainers should research? Along
with the possibility of switching lang/rust back to the llvm provided by
the base (best) or installed by a port (second best)?
Good luck. Make sure to test in a clean environment e.g., via poudriere
Jan, this is the job of the port's maintainer... The current situation
-- requiring a rebuild of LLVM twice -- is ridiculous, should never have
come about, and should not remain for long. I hope, we agree on the
first and the second, at least...
I can't see, what good llvm-objdump could do to the vast majority of users.
See https://hg.mozilla.org/mozilla-central/rev/53d93ee3ad84
While the commit was backed out the configure check wasn't, so maybe
the intent is to reland in future.
So, it is not even being used?! And, if it were, it would only be for
some build-time library-reading, which the port could disable...
And if it does something good, llvm-objdump is already part of base
(at least, on this 12.0-STABLE laptop I'm trying to dress up)...
llvm-objdump is only installed when src.conf(5) has WITH_CLANG_EXTRAS.
Ports have to build against default base configuration.
I don't have that knob defined on this 12.0 system, but llvm-objdump is
installed anyway -- perhaps, on 12.0 it is on by default. At any rate,
it is a) not used, b) not needed, c) is a small utility, which, if
actually needed, could've been installed via a port of its own.
-mi
_______________________________________________
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"
