- 0b559eab04/yjit/yjit.mk (L22-L27)
Only `$RUSTC`, which desugars to `rustc` by default, is used for yjit.
Note that the plumbing for cargo does exist, but is used for development
purposes only.
Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
(cherry picked from commit 90e5b96d7fc14cd8b4e290769f4d188e75329a32)
Otherwise it will produce `yjit.a` with the default target for the
`rustc` compiler, which in turn turns out to be the build platform?
It could be configured using the `RUST` environment variable, and
since it's used without quoting it would expand the arguments added
to it.
Using `RUST = "rust --target ..."` I think would be undesirable for
cross-compiling (and native), since it will save those arguments in
`lib/ruby/*/*/rbconfig.rb`. Though that might be fine too. I guess.
Note that 3.2 breaks differently. I haven't investigated it, since it's
not the default anymore, and will eventually be dropped.
Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
(cherry picked from commit 75d6216956bfb72a2a1082da7237f74dddf8e123)
This commit, together with https://github.com/NixOS/nixpkgs/pull/442540,
changes the way python environments are built:
* When generating wrappers for python executables, we inherit argv[0]
from the wrapper. This causes python to initialize its configuration
in the environment with all the correct paths.
* We also resolve argv[0] to absolute path when invoking python from
PATH. This helps set python's prefix correctly on Darwin.
The end result is that python environments no longer appear to be venvs,
and behave more like a vanilla python installation. In addition it's
possible to create a venv using an environment and use packages from
both the environment and the venv.
else we get the typical:
```
➜ ./result/bin/scide
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.
```
Perl uses GNU extensions if they are available. Its build system
tries to detect whether the libc is one that recognizes _GNU_SOURCE
with bad heuristics, that don't work for e.g. riscv64 musl. Upstream
is not willing to unconditionally set _GNU_SOURCE like programs
usually do, because of an IMO misguided fear of somebody one day
writing a libc that interprets _GNU_SOURCE to mean something
different, so the only thing we can really do is set it ourselves.
On libcs that don't gate GNU extensions behind _GNU_SOURCE, like BSDs,
this should be a no-op. This should also improve things for cross
where musl builds are currently broken due to perl-cross setting
_GNU_SOURCE for the configure step but not the build step, although I
haven't tested that.
Link: https://github.com/Perl/perl5/issues/16807#issuecomment-544099623
Link: https://github.com/arsv/perl-cross/issues/158
