forked from gentoo/gentoo
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit 4f1ee98
committed
dev-lang/perl: Enforce toolchain
This one neat trick convinces ./configure to use a correct, and
specified "ar" during configure, as auto-detection completely fails
when there is no binary named "ar" in $PATH, and despite completely
failing to detect any "ar", configure just warns, and continues as
normal, and then hardcodes that total failure of detection in
Config_heavy.pl, indicating "hey, the 'ar' perl was built with was
'ar'", despite no such thing existing, and code afterwards will then
try ( and fail ) to use that `ar` by consulting $Config{ar}
This step compeletely side-steps auto-detection, so at very least,
Config_heavy.pl contains a value that at least one time, probably
worked, and as a result, large amounts of EUMM/MB XS stuff no longer
tries to use a default `ar` that never existed.
-r1 bump required, as the consequences of this change propagate into
everything that compiles C code against Perl, and a failure to upgrade
perl with this fix results in future failures compiling other stuff
But otherwise this really is just a one line fix:
```diff
--- perl-5.30.2.ebuild 2020-04-13 01:31:59.268561073 +1200
+++ perl-5.30.2-r1.ebuild 2020-05-18 16:46:13.972962817 +1200
@@ -507,4 +507,5 @@
-Darchname="${myarch}" \
-Dcc="$(tc-getCC)" \
+ -Dar="$(tc-getAR)" \
-Doptimize="${CFLAGS}" \
-Dldflags="${LDFLAGS}" \
```
Bug: https://bugs.gentoo.org/723264
Bug: https://bugs.gentoo.org/723154
Bug: Perl/perl5#17791
Package-Manager: Portage-2.3.99, Repoman-2.3.22
Signed-off-by: Kent Fredric <[email protected]>ar
in ./configure1 parent 06bc902 commit 4f1ee98Copy full SHA for 4f1ee98
1 file changed
+654
-0
lines changed
0 commit comments