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