How do module directories get associated with specific installation locations of perl? When I install a module, I just do the following (as an example):

cd /home/user/perl_modules
cpanm -L$PWD Devel::NYTProf
[download]

How do module directories get associated with specific installation locations of perl?

Easy: The library paths are compiled into the perl binary. In case of Linux, most of the library paths are actually in libperl.so, the perl executable is barely more than a stub that contains just enough code to load libperl.so, and the directory where libperl.so can be found:

/home/alex>cd /usr/bin/

/usr/bin>strings perl | grep /usr
/usr/lib64/perl5/CORE

/usr/bin>ldd perl
        linux-vdso.so.1 (0x00007ffe43ef0000)
        libperl.so => /usr/lib64/perl5/CORE/libperl.so (0x00007f2387f4
+3000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2387d26000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f2387b0c000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f2387908000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f23875ff000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f23873c7000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f23871c4000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f2386dfb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2388327000)

/usr/bin>strings /usr/lib64/perl5/CORE/libperl.so | grep /usr
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5

/usr/bin>./perl -E 'say for @INC'
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5
.

/usr/bin>ls -l perl perl5.22.2
lrwxrwxrwx 1 root root    10 Jan  8  2017 perl -> perl5.22.2*
-rwxr-xr-x 1 root root 10376 Apr 30  2016 perl5.22.2*

/usr/bin>
[download]

The CPAN utilities (or, to be more precise: the module build utilties) install into the directories that were choosen when perl was configured. That information is available via Config, and is actually stored in Config_heavy.pl:

/usr/bin>grep /usr /usr/lib64/perl5/Config_heavy.pl |grep perl
archlib='/usr/lib64/perl5'
archlibexp='/usr/lib64/perl5'
ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'
config_arg10='-Dvendorarch=/usr/lib64/perl5/vendor_perl'
config_arg4='-Dsitelib=/usr/local/share/perl5'
config_arg5='-Dsitearch=/usr/local/lib64/perl5'
config_arg6='-Darchlib=/usr/lib64/perl5'
config_arg8='-Dprivlib=/usr/share/perl5'
config_arg9='-Dvendorlib=/usr/share/perl5/vendor_perl'
config_args='-de -Dprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/
+local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Darchlib=/usr/li
+b64/perl5 -Dvendorprefix=/usr -Dprivlib=/usr/share/perl5 -Dvendorlib=
+/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_per
+l -Dscriptdir=/usr/bin -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dlibp
+th=/usr/local/lib64 /usr/lib64 /lib64 -Doptimize=-O2 -fPIC -Dusethrea
+ds -Duseithreads -Duseshrplib -Ubincompat5005 -Uversiononly -Dpager=/
+usr/bin/less -isr -Darchname=x86_64-linux'
installarchlib='/usr/lib64/perl5'
installprivlib='/usr/share/perl5'
installsitearch='/usr/local/lib64/perl5'
installsitelib='/usr/local/share/perl5'
installvendorarch='/usr/lib64/perl5/vendor_perl'
installvendorlib='/usr/share/perl5/vendor_perl'
perlpath='/usr/bin/perl'
privlib='/usr/share/perl5'
privlibexp='/usr/share/perl5'
sitearch='/usr/local/lib64/perl5'
sitearchexp='/usr/local/lib64/perl5'
sitelib='/usr/local/share/perl5'
sitelib_stem='/usr/local/share/perl5'
sitelibexp='/usr/local/share/perl5'
startperl='#!/usr/bin/perl'
vendorarch='/usr/lib64/perl5/vendor_perl'
vendorarchexp='/usr/lib64/perl5/vendor_perl'
vendorlib='/usr/share/perl5/vendor_perl'
vendorlib_stem='/usr/share/perl5/vendor_perl'
vendorlibexp='/usr/share/perl5/vendor_perl'

/usr/bin>
[download]

The build modules simply load and query Config, simply by using use or require. Config.pm and Config_heavy.pl are created when perl is compiled, and installed into one of the directories compiled into the binaries. Because each perl has its own set of include directories, simply loading Config.pm is sufficient (unless someone has messed with @INC or the data in Config.pm or Config_heavy.pl - see the warning in Config).

(All examples from Slackware Linux 14.2 64 bit, using the system perl.)

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

It seems I have multiple sources of confusion here. First of all, the Devel::NYTProf module directory contains the following file (referenced in the error message in my OP):

/user/perl_modules/lib/perl5/x86_64-linux/Devel/auto/Devel/NYTProf/NYT
+Prof.so
[download]

Which appears to be called using this line in /user/perl_modules/lib/perl5/x86_64-linux/Devel/NYTProf/Core.pm:

XSLoader::load('Devel::NYTProf', $VERSION);
[download]

Based on a cursory search this appears to be a way to include a library of separate C/C++ functions and access them from within perl. Is that correct? If so, then that probably explains why I've never run into this error until now - other modules I've installed and referenced from /user/perl_modules/lib/perl5 didn't have dynamic libraries.

Having said that, based on my C/C++ experience linker errors such as "undefined symbol" occur when the executable doesn't have a path to the referenced dynamic library, which can be checked using the "ldd" command. If I run "ldd /usr/bin/perl", it returns the following:

> ldd /usr/bin/perl
linux-vdso.so.1 =>  (0x00007ffc0b140000)
libperl.so => /usr/lib64/perl5/CORE/libperl.so (0x00007f74bbaa5000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f74bb88c000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f74bb672000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f74bb46e000)
libm.so.6 => /lib64/libm.so.6 (0x00007f74bb16c000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f74baf35000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f74bad32000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f74bab16000)
libc.so.6 => /lib64/libc.so.6 (0x00007f74ba749000)
/lib64/ld-linux-x86-64.so.2 (0x00007f74bbe33000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f74ba546000)
[download]

whereas "ldd /tool/bin/perl" returns the following:

> ldd /tool/bin/perl
linux-vdso.so.1 =>  (0x00007ffeeebb7000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f3a2cd0f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3a2cb0b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f3a2c809000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f3a2c5d2000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f3a2c002000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3a2c002000)
/lib64/ld-llinux-x86-64.so.2 (0x00007f3a2cf29000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f3a2bdff000)
[download]

Note that neither perl installation has /user/perl_modules/lib/perl5/x86_64-linux/Devel/auto/Devel/NYTProf/ in its list of ldd paths, so how was /tool/bin/perl able to find NYTProf.so but /usr/bin/perl was not?
Also the ldd paths for a given perl installation are completely separate from the paths contained in @INC when that perl executable is run, correct?

It's not so much associated with a specific install location, but the version and settings of a specific build of perl.

The perl that was used to install them. (head -n 1 "$( type -p cpanm )" )

Upd: Added missing -p.

Seeking work! You can reach me at ikegami@adaelis.com

type or which?

This stackoverflow post looks relevant: https://stackoverflow.com/questions/41903944/what-is-the-default-path-for-cpanm-to-install-perl-modules.

It links to the cpanm docs at https://metacpan.org/pod/App::cpanminus#Where-does-this-install-modules-to?-Do-I-need-root-access? .