Your skill will accomplish what the force of many cannot |
|
PerlMonks |
Re: Problem Installing Perl-Tk on macOS Monterey (12.6) with Apple M1 chipby bliako (Monsignor) |
on Oct 05, 2022 at 07:40 UTC ( [id://11147254]=note: print w/replies, xml ) | Need Help?? |
Firstly, check to see if perlbrew's perl is the one being used (as well as cpan) and not system perl: which perl; which cpan. Secondly, check to see if the modules you installed via perlbrew's cpan/cpanm do install in their proper locations and that the correct modules are loaded (where "incorrect" modules are those loaded from system perl's INC places). Useful here is the @INC : perl -e 'print "@INC"' Thirdly, the other interference from system perl+tk would be that their binary libraries (.so, .dylib) are loaded instead of perlbrew's perl+tk. You can check/affect that with the env vars: LD_LIBRARY_PATH and DYLD_LIBRARY_PATH and, better, sieve through the output of strace perl (consequently: strace /Library/Developer/CommandLineTools/usr/bin/make all-am (note: I am not sure if this command will recursively strace all the calls inside the Makefile). I think with the above you can detect where libraries and modules are loaded from, and, therefore, eliminate the possibility of "interference" from system perl+tk. Using an older macOS is a bless and a curse: the newer (13.+) are locking the system with the so-called SIP with a really annoying effect: (DY)LD_LIBRARY_PATH env vars are *forbidden* (by the cupertino directorate) to be passed to executables, so this DYLD_LIBRARY_PATH=my-good-tk-libraries make all-am will have no effect and still be looking in /usr/lib first. The curse of course is that nothing works and the one daring to use older hardware feels like a leper, not least by the various forums' support. bw, bliako
In Section
Seekers of Perl Wisdom
|
|