Investigating an issue with multiple Perl installations on our (HP UX IA64 system), I came across an executable called perl-dynamic. What is this and what exactly does it do?
More importantly, how do I know which perl executable it actually points to (we have multiple versions mixing version numbers and architectures installed).
bash-4.4$ ll /usr/bin/perl
lrwxr-xr-x 1 root sys 18 Jan 8 16:34 /usr/bin/perl -> /opt/perl/bin/perl
bash-4.4$ ll /opt/perl/bin/perl
lrwxrwxrwx 1 bin bin 14 Jan 8 16:45 /opt/perl/bin/perl -> ./perl-dynamic
Is this a magical perl binary which decides which version and architecture to use?
$ perl -V
Will show you the details.
Both perl-static and perl-dynamic are built with the same configuration (at least for what I can see on my HP-UX 11.31) and both are built with -Dusedl
perl-static is linked with libperl.a (or linked with all .o files), whereas perl-dynamic is linked using libperl.so. You can check the differences with ldd perl-static and ldd perl-dynamic.
There is no functional difference
Related
Running RHEL 7.7 on the head node of a compute cluster. When I open VS Code 1.57.1 it hangs on the intro screen. Running with $ code --verbose, it shows the error: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.20 not found. I have to kill -9 the hanging code process. Google tells me that the new version of VS Code uses Electron that requires the updated GLIBCXX version.
The installed version in /usr/lib64/libstdc++ is definitely out of date, and I can't update it. But I do have a newer version of GCC that is loaded by the $ module load gcc8/8.4.0 command that loads GCC from /cm/shared/apps/gcc8/8.4.0/. The library /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 has the requested version of GLIBCXX.
I have tried loading gcc8 before running code, but that doesn't change the error.
Is there a way to make VS Code use the alternative location for libstdc++.so.6? Is there an alternative to updating the system-wide libstdc++.so.6 library?
This is the full error message from --verbose:
Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1846)
This shows the out-of-date default version of libstdc++:
$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.18
GLIBCXX_3.4.19 <----Nope, this version is too old!
GLIBCXX_DEBUG_MESSAGE_LENGTH
This shows the other libstdc++ library has the required version:
$ strings /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.19
GLIBCXX_3.4.20 <--- Here it is!
GLIBCXX_3.4.21
...
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH
Per scroveez's suggestion, the /usr/lib64/libstdc++.so.6 was indeed a symlink to the older version. To fix it I copied the 'new' version 25 library into /usr/lib64/ and changed the symlink to point to the newer version.
$ ll /usr/lib/libstdc++.so.*
lrwxrwxrwx 1 root root 18 Apr 30 2019 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
-rwxr-xr-x 1 root root 739520 Nov 13 2014 /usr/lib/libstdc++.so.5.0.7
lrwxrwxrwx 1 root root 19 Jul 6 08:56 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.25
-rwxr-xr-x 1 root root 934644 Mar 25 2020 /usr/lib/libstdc++.so.6.0.19
-rwxr-xr-x 1 root root 1570176 Jul 6 08:55 /usr/lib/libstdc++.so.6.0.25
$
I am puzzled by the following sequence of commands.
sh-4.2$ pwd
/home/willard
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ file f
f: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0xea0e08ff2b5a062698d45b78177acdd6bf140d1f, stripped
sh-4.2$ ./f
sh: ./f: No such file or directory
sh-4.2$ strace ./f
execve("./f", ["./f"], [/* 32 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ uname -a
Linux xdat10 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux
How is this possible?
I found someone having the same problem (with relative explanation)
Running 32bit binary on a 64bit system
Quoting the most important sentences:
This situation often arises when you try to run a binary for the right
system (or family of systems) and superarchitecture but the wrong
subarchitecture. Here you have ELF binaries on a system that expects
ELF binaries, so the kernel loads them just fine. They are i386
binaries running on an x86_64 processor, so the instructions make
sense and get the program to the point where it can look for its
loader. But the program is a 32-bit program (as the file output
indicates), looking for the 32-bit loader /lib/ld-linux.so.2, and
you've presumably only installed the 64-bit loader
/lib64/ld-linux-x86-64.so.2 in the chroot.
You need to install the 32-bit runtime system in the chroot: the
loader, and all the libraries the programs need. On Debian amd64, the
32-bit loader is in the libc6-i386 package. You can install a bigger
set of 32-bit libraries by installing ia32-libs.
I bet there's a better way to verify this but i'd try to exec
ldd ./f
and search in the output which loader is needed to exec'it
man 2 execve:
ENOENT The file filename or a script or ELF interpreter does not
exist, or a shared library needed for file or interpreter can‐
not be found.
You could run ldd against this binary to look for libraries that could not be mapped and install them from multilib.
I'm simply trying to get a list of filenames given a path with wildcard.
my $path = "/foo/bar/*/*.txt";
my #file_list = glob($path);
foreach $current_file (#file_list) {
print "\n- $current_file";
}
Mostly this works perfectly, but if there's a file greater than 2GB, somewhere in one of the /foo/bar/* subpaths, the glob returns an empty array without any error or warning.
If I remove the file file or add a character/bracket sequence like this:
my $path = "/foo/bar/*[0-9]/*.txt";
or
my $path = "/foo/bar/*1/*.txt";
then the glob works again.
UPDATE:
Here's an example (for a matter of business policy I had to mask the pathname):
[root]/foo/bar # ls -lrt
drwxr-xr-x 2 root system 256 Oct 11 2006 lost+found
drwxr-xr-x 2 root system 256 Dec 27 2007 abc***
drwxr-xr-x 2 root system 256 Nov 12 15:32 cde***
-rw-r--r-- 1 root system 2734193149 Nov 15 05:07 archive1.tar.gz
-rw-r--r-- 1 root system 6913743 Nov 16 05:05 archive2.tar.gz
drwxr-xr-x 2 root system 256 Nov 16 10:00 fgh***
[root]/foo/bar # /home/user/test.pl
[root]/foo/bar #
Removing the >2GB file (or globbing with "/foo/bar/[acf]/" istead of "/foo/bar//")
[root]/foo/bar # ls -lrt
drwxr-xr-x 2 root system 256 Oct 11 2006 lost+found
drwxr-xr-x 2 root system 256 Dec 27 2007 abc***
drwxr-xr-x 2 root system 256 Nov 12 15:32 cde***
-rw-r--r-- 1 root system 6913743 Nov 16 05:05 archive2.tar.gz
drwxr-xr-x 2 root system 256 Nov 16 10:00 fgh***
[root]/foo/bar # /home/user/test.pl
- /foo/bar/abc***/heapdump.phd.gz
- /foo/bar/cde***/javacore.txt.gz
- /foo/bar/fgh***/stuff.txt
[root]/foo/bar #
Any suggestion?
I'm working with:
Perl 5.8.8
Aix 5.3
The filesystem is a local jfs.
In the absence of a proper answer you're going to want a work-around. I'm guessing you've hit some platform-specific bug in the glob() implementation of 5.8.8
I had a quick look at the source on CPAN but my C is too rusty to spot anything useful.
There have been lots of changes to that module though, so a bug may well have been reported and fixed. You're not even on the last release of 5.8 - there's a 5.8.9 out there which mentions updates to AIX compatibility and File::Glob.
I'd test this by installing local::lib if you haven't already and then perhaps cpanm and try updating File::Glob - see what that does. You might need to download the files by hand from e.g. here
If that solves the problem then you can either deploy updates to the required systems, or you'll have to re-implement the bits of glob() you want. Which is going to depend on how complex your patterns get.
If it doesn't solve the problem then at least you'll be able to stick some printf's into the code and see what it's doing.
Hopefully someone will post a real answer and make this redundant about 5 minutes after I click "Post Your Answer" though.
I've never used the new Glob function before, so i cant comment on benefits/problems, but it seems quite a lot of people have had issues using it: see => https://stackoverflow.com/search?q=perl+glob&submit=search for some questions and possible solutions.
IF you don't mind trying out something else:
Here is my tried and tested 'old school' perl solution i have used in countless projects:
my $path = "/foo/bar/";
my #result_array = qx(find $path -iname '*.txt'); #run the system find command
If you - for whatever reason prefer not to run a system command from within your script, then lookup the built in Find::Perl Module instead: http://search.cpan.org/~dom/perl-5.12.5/lib/File/Find.pm
good luck
I want to connect with the oracle database from a perl script in solaris servier. Able to see DBI is installed but not DBD::Oracle in the current perl version 5.8.4. I dont have root acess and working on my home user id. Download the DBD-Oracle-1.50 and unzipped in the local directory where my perl script exists. I want to copy the DBD Oracle library files into a custom directory and run the script since i dont have root acess. When i read the install script in the DBD-Oracle-1.50 it's says for manuall install i need to run the below scripts . Since i dont have root access i want to copy the library modules into the local directory. Not sure how to tell these scripts to install it in the local directory where my perl script exists.
Does installing DBI and DBD in a custom directory under my user id makes it work properly. Do those modules require root access to work properly? To use DBD::Oracle does oracle needs to be installed in server. My Understanding Oracle driver DBD::Oracle should take care of it.
perl Makefile.PL
make && make test
make install
> ls -tlr /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int total 956
> -rwxr-xr-x 1 root bin 15161 Mar 26 2005 Roadmap.pod
> -rwxr-xr-x 1 root bin 1048 Sep 5 2006 TASKS.pod
> -rwxr-xr-x 1 root bin 289343 Jun 26 2007 DBI.pm
> -rwxr-xr-x 1 root bin 4608 Jun 12 2008 goferperf.pl
> -rwxr-xr-x 1 root bin 1356 Jun 12 2008 dbixs_rev.pl
> -rwxr-xr-x 1 root bin 58386 Apr 3 2010 SNMP.pm drwxr-xr-x 3 root bin 7 Oct 13 2010 NetSNMP
> drwxr-xr-x 2 root bin 3 Oct 13 2010 Win32 drwxr-xr-x
> 8 root bin 19 Oct 13 2010 DBI drwxr-xr-x 2 root
> bin 4 Oct 13 2010 Bundle drwxr-xr-x 6 root other
> 6 Oct 13 2010 auto drwxr-xr-x 3 root bin 11 Oct 13
> 2010 DBD
>
> ls -ltr /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int/DBD total 543
> -rwxr-xr-x 1 root bin 111586 May 6 2006 Pg.pm
> -rwxr-xr-x 1 root bin 28785 Sep 27 2006 Proxy.pm
> -rwxr-xr-x 1 root bin 7937 Jan 25 2007 Sponge.pm
> -rwxr-xr-x 1 root bin 42836 Feb 6 2007 DBM.pm
> -rwxr-xr-x 1 root bin 19882 Mar 28 2007 File.pm
> -rwxr-xr-x 1 root bin 12051 May 10 2007 ExampleP.pm
> -rwxr-xr-x 1 root bin 43586 May 14 2007 Gofer.pm
> -rwxr-xr-x 1 root bin 3761 Jun 15 2007 NullP.pm drwxr-xr-x 4 root bin 4 Oct 13 2010 Gofer
If DBI is already installed, you should only need to install DBD::Oracle, though you might want to install a later version of DBI. You can install DBD::Oracle under your home directory, then set the PERL5LIB environment variable to that directory (or to include that directory). The long way to install is:
perl Makefile.PL PREFIX=~/perl #Or whatever sub-directory you like
make
make test
make install
Then include at least "~/perl/lib;~/perl/lib/site_perl" in PERL5LIB before running your programs (or include a 'use lib" in your programs).
You can also set certain environment variables like PERL_MM_OPT and PERL_MB_OPT so that you don't have to specify the PREFIX= on the command line (see docs for ExtUtils::MakeMaker and Module::Build). I also recommend cpanm and setting PERL_CPANM_HOME to something under your home directory.
Perl modules can be very well installed in a custom directory. This situation usually arises when you don't have root access to install the PM. Once you have installed DBI and DBD in your custom folder there are several different ways to make sure that perl is aware of this installation.
1. Set the environment variable PERL5LIB
Perl will look for modules in the directories specified in PERL5LIB environment variable before looking in the standard library and current directory, so you can set this variable to locate your modules.
The syntax is the same you use for the PATH environment variables, so you separate the directories with colons on unix and with a semicolon on Windows.
Example:
# unix, bourne shell
PERL5LIB=/home/path/lib:/usr/another/path/lib; export PERL5LIB
Be aware that scripts running with -T option (taint checks) do not use that variable, so in those cases this option won't work.
2. Use '-I' command line parameter
The syntax should be something like:
perl -I /home/path/lib -I /usr/another/lib script.pl
3. Add the library path in your script
The command for including the path in your script is: use lib "path".
Notice that this statement prepends "path" to the #INC array, so it's basically the same as unshift #INC, "path"
Example:
#!/usr/bin/perl
use lib "/home/path/lib";
use lib "/usr/another/lib";
It seems I have a configuration problem when installing Perl modules through CPAN and I don't know how to correct it:
[root#ip JESSE]# pwd
/root/.cpan/sources/authors/id/J/JE/JESSE
[root#ip JESSE]# ls -l
total 240
-rw-r--r-- 1 root root 105464 Feb 20 11:39 CHECKSUMS
-rw-r--r-- 1 root root 9223 Apr 12 2011 Locale-Maketext-Simple-0.21.tar.gz
-rw-r--r-- 1 root root 125483 Feb 20 11:39 WWW-Mechanize-1.72.tar.gz
[root#ip JESSE]# cpan -i WWW::Mechanize
CPAN: Storable loaded ok (v2.20)
Reading '/root/.cpan/Metadata'
Database was generated on Mon, 20 Feb 2012 11:10:26 GMT
Running install for module 'WWW::Mechanize'
Running make for J/JE/JESSE/WWW-Mechanize-1.72.tar.gz
CPAN: Digest::SHA loaded ok (v5.61)
CPAN: Compress::Zlib loaded ok (v2.033)
Checksum for /root/.cpan/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz ok
CPAN: Archive::Tar loaded ok (v1.82)
Uncompressed /root/.cpan/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz successfully
Using Tar:/bin/tar xvf "WWW-Mechanize-1.72.tar":
Couldn't untar WWW-Mechanize-1.72.tar
CPAN: File::Temp loaded ok (v0.22)
CPAN: CPAN::Meta loaded ok (v2.112150)
Package seems to come without Makefile.PL.
(The test -f "/root/.cpan/build/JESSE-n72IRU/Makefile.PL" returned false.)
Writing one on our own (setting NAME to WWWMechanize)
Had problems unarchiving. Please build manually
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
[root#ip JESSE]# ls -l
total 240
-rw-r--r-- 1 root root 105464 Feb 20 11:39 CHECKSUMS
-rw-r--r-- 1 root root 9223 Apr 12 2011 Locale-Maketext-Simple-0.21.tar.gz
-rw-r--r-- 1 root root 125483 Feb 20 11:39 WWW-Mechanize-1.72.tar.gz
[root#ip JESSE]# which tar
/bin/tar
[root#ip JESSE]# which gzip
/bin/gzip
The problem seems to be here:
Uncompressed /root/.cpan/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz successfully
Using Tar:/bin/tar xvf "WWW-Mechanize-1.72.tar":
Couldn't untar WWW-Mechanize-1.72.tar
The tar.gz file is indeed uncompressed and can be found here in a new directory:
/root/.cpan/build/JESSE-KjCEMS/WWW-Mechanize-1.72.tar
If I run the same command from inside the shell, I get some more info:
cpan[1]> install WWW::Mechanize
CPAN: Storable loaded ok (v2.20)
Reading '/root/.cpan/Metadata'
Database was generated on Mon, 20 Feb 2012 11:10:26 GMT
Running install for module 'WWW::Mechanize'
Running make for J/JE/JESSE/WWW-Mechanize-1.72.tar.gz
CPAN: Digest::SHA loaded ok (v5.61)
CPAN: Compress::Zlib loaded ok (v2.033)
Checksum for /root/.cpan/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz ok
Scanning cache /root/.cpan/build for sizes
Use of uninitialized value $newdir in substitution (s///) at /usr/lib64/perl5/Cwd.pm line 502.
Use of uninitialized value $newdir in chdir at /usr/lib64/perl5/Cwd.pm line 510.
Use of chdir('') or chdir(undef) as chdir() is deprecated at /usr/lib64/perl5/Cwd.pm line 510.
Use of uninitialized value $newdir in pattern match (m//) at /usr/lib64/perl5/Cwd.pm line 525.
Use of uninitialized value $newdir in split at /usr/lib64/perl5/Cwd.pm line 531.
..........................................................................--DONE
DEL(1/10): /root/.cpan/build/CPAN-1.9600-jGTV10
DEL(2/10): /root/.cpan/build/File-Which-1.09-yoVWZC
DEL(3/10): /root/.cpan/build/Test-Script-1.07-aJWrXb
DEL(4/10): /root/.cpan/build/Probe-Perl-0.01-gzZ2eR
DEL(5/10): /root/.cpan/build/IPC-Run3-0.044-AP6EMp
DEL(6/10): /root/.cpan/build/Time-HiRes-1.9721-xxseE6
DEL(7/10): /root/.cpan/build/CPAN-Meta-YAML-0.003-wGtH0a
DEL(8/10): /root/.cpan/build/JSON-PP-2.27105-fvkwNa
DEL(9/10): /root/.cpan/build/Package-Constants-0.02-7Ms_OL
DEL(10/10): /root/.cpan/build/Module-Metadata-1.000004-tXKIBB
CPAN: Archive::Tar loaded ok (v1.82)
Uncompressed /root/.cpan/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz successfully
Using Tar:/bin/tar xvf "WWW-Mechanize-1.72.tar":
Couldn't untar WWW-Mechanize-1.72.tar
CPAN: File::Temp loaded ok (v0.22)
CPAN: CPAN::Meta loaded ok (v2.112150)
Package seems to come without Makefile.PL.
(The test -f "/root/.cpan/build/JESSE-DGrTh_/Makefile.PL" returned false.)
Writing one on our own (setting NAME to WWWMechanize)
Had problems unarchiving. Please build manually
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
Failed during this command:
JESSE/WWW-Mechanize-1.72.tar.gz : unwrapped NO -- untar failed
It seems to me that $newdir is not being updated with the dynamically generated /root/.cpan/build/JESSE-DGrTh_/ or /root/.cpan/build/JESSE-KjCEMS/ or whatever the system generates or at least that information is not getting to the tar command
Does anyone know how I can fix the mechanism without having to resort to a manual install ?
Edit:
I ran into this problem again. All I needed to do was free some memory like Keith Broughton suggested.
I ran into the same problem and tried to find the root cause for this problem. I'm listing my findings here so other Googlers don't have to spend a couple of hours before giving up...
What solved it for me was simply rebooting the system.
Things I tried:
Upgrading CPAN. This would also fail with the "Couldn't untar" error message. I doesn't matter if you try it using the cpan shell, "cpan -i CPAN" or "perl -MCPAN -e 'install CPAN'". I didn't think any of these would solve the problem, but when you start googling all these are suggested as possible solutions.
Replacing tar with a script that logs its input to check if one of the parameters or cwd is incorrect when it is called. The script is never called it seems. The "Couldn't untar" message is still the same, even after temporarily renaming /bin/tar.
Checking CPAN/Tarzip.pm and adding print lines near the code that writes the "Couldn't untar" message. It seems that the system() call fails and tar (or ls in my debug code) is never called.
Then I decided to reboot, which was an option because this is not a live system. After that the problem was gone and Perl modules installed on first try.
Other observations:
The system seems to work just fine for the rest. You can still connect to the system, you can edit files, modifications are still there after the reboot. I would expect any of these to fail long before a Perl system() call starts to fail.
A quick scan through the logfiles doesn't show any red flags.
Sometimes this can happen simply due to a lack of available memory. Try turning off some services that are running and try again.
Worked for me :-)
To resolve the following error:
Couldn't untar WWW-Mechanize-1.72.tar
Try install Archive::Tar
On centos 6.X:
yum install perl-Archive-Tar.x86_64
Found the same issue on DigitalOcean droplet with 512MB RAM running Ubuntu (with about 200MB free).
I was able to solve it by rebooting the machine, I tried updating my CPAN using 'install Bundle::CPAN'. It worked for the first few modules, and then the 'Couldn't untar' message appeared again.
Rebooting allowed me to progress in the installation. These repeated reboots are of course a less than optimal solution.
Given that the system has free memory, and the issue re-appears after using the machine for a little while, it seems to be this could be related to an issue with shared libraries.
Shot in the blue: partition is full. Delete some files.