in reply to Re: Devel::NYTProf: "undefined symbol: PL_stack_sp" error
in thread Devel::NYTProf: "undefined symbol: PL_stack_sp" error

If I include the following in factorial_recurse.pl:

printf("perl5lib = $ENV{PERL5LIB}");

It prints:

perl5lib = /home/user/perl_modules/lib/perl5/x86_64-linux/

and nothing else. I don't see a path to either perl version referenced in my previous post (/tool/bin/perl

or

/usr/bin/perl

). Is that a problem?

Replies are listed 'Best First'.
Re^3: Devel::NYTProf: "undefined symbol: PL_stack_sp" error
by swl (Prior) on Aug 26, 2021 at 22:53 UTC

    The issue is that the libraries under that path are compiled for one of your perls, but not the other.

    You need to have a separate directory for each perl version, each of which has a version of the libraries you are using. This is what Corion was recommending in 11136089.

    A slightly more involved, but well tested and used, way to achieve this is to use local::lib to handle the different directories.

      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
        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>

        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>

        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'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