I have some old production computer which has Perl 5.0 (updated version 1998).
I developed a script on my office computer with Activestate Perl 5.24.1
When i tried to run on the older version (installed on Windows XP) it drops several warnings, etc can not know about USE Warnings;, or three parameter open function.
The our keyword cannot be used with use strict;
our %Config = (
'SourcePath' => "",
'TargetPath' => "",
'Station' => "",
'Product' => "",
'LogLevel' => 0
);
When i tried to print a string with a hash variable in, it drops a warning too.
The code is:
print $fhw qq/ <FACTORY NAME="FLEX_ZALA" TESTER="$Config{'Station'}" FIXTURE="" USER="" LINE="" SHIFT="" \/>\n/;
The Station variable is not known for it.
I cannot develop on a production machine, but cannot install this old version on my office computer too.
How can i force to run my script with perl 5.24.1 in compatibily mode 5.0?
I using a windows 7 X64 PC for office.
Thanks.
UPD1:
The XP Perl version is:
Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001
Microsoft Corp.
C:\Documents and Settings\grprog1>perl -v
This is perl, version 5.003_07
Copyright 1987-1996, Larry Wall
+ suidperl security patch
Win32 port Copyright (c) 1995-1996 Microsoft Corporation.
All rights reserved.
Developed by ActiveWare Internet Corp., http://www.ActiveWare.com
Perl for Win32 Build 316 - Built 09:44:44 Mar 13 1998
Perl may be copied only under the terms of either the Artistic License
or the GNU General Public License, which may be found in the Perl 5.0
source kit.
UPD2:
C:\Documents and Settings\grprog1>perl -V Summary of my perl5 (patchlevel 1) configuration: Platform:
osname=MSWin32, osver=3.51, archname=i386-win32
uname=''
hint=recommended Compiler:
cc='cl', optimize=''
cppflags=''
ccflags =''
ldflags =''
stdchar='char', d_stdstdio=, usevfork=false
voidflags=15, castflags=0, d_casti32=, d_castneg=
intsize=4, alignbytes=4, usemymalloc=n, randbits=15 Libraries:
so=dll
libpth=
libs=
libc= Dynamic Linking:
dlsrc=dl_win32.xs, dlext=pll, d_dlsymun=
cccdlflags='', ccdlflags='', lddlflags=''
Characteristics of this binary (from libperl): Built under MSWin32 Compiled at Mar 13 1998 09:44:44 #INC:
C:\Teradyne\GRNavigate\228x\lib\perl
..\lib\i386-win32
..\lib
.
If I understand you correctly, you have Computer A which has perl 5.003_7. Therefore, copying that distribution from Computer A to Computer B where you want to do development is the most straightforward answer.
You say the testers also have this version of Perl. Therefore, your company must have bought either a site license or some specific number of licenses from ActiveState. You should investigate that first.
If you are stuck, contact ActiveState for support. They may provide you one for a fee.
Your company, however, faces the problem of having operations depend on ancient, no longer supported software to run programs which probably have problems of their own. It would be a good idea to move into this century.
If you absolutely must, no way around it, run ancient perl, your scripts cannot use more modern stuff.
Check out perlbrew to have more than one version of perl on your development/test box so you can test your code on several versions of perl with one command.
And perhaps also http://perldoc.perl.org/perl.html to see the docs of older perls.
It goes back only to 5.8.8 (~2005), but better than using docs for 5.24 in your situation.
Related
I run into this every so often: I run a brew install foobar and as a result, Perl version gets updated. Whenever this happens, the Perl modules that I had installed are no longer found because they were installed in /usr/local/Cellar/perl/5.32.0/lib/perl5/site_perl/5.32.0/ and the new version is now looking in /usr/local/Cellar/perl/5.32.0/lib/perl5/site_perl/5.32.1_1/.
I have/had a ton of modules installed with the previous version and I'd rather not reinstall all of them (at least manually). What's the best way to have the previously-installed modules work with the new Perl version?
For such a small version change above, I could presumably just copy all of the files from the 5.32.0 dir to the 5.32.1_1 dir, but preferably there is a more general and/or robust solution for when the version change is more substantial.
The cpan command can make an "autobundle" file. You'd use the cpan from the prior installation to do this:
$ cpan -a
Creating autobundle in /Users/brian/.cpan/Bundle
Reading '/Users/brian/.cpan/Metadata'
Database was generated on Fri, 19 Mar 2021 05:41:03 GMT
Package namespace installed latest in CPAN file
Algorithm::C3 0.11 0.11 HAARG/Algorithm-C3-0.11.tar.gz
Algorithm::Cron 0.10 0.10 PEVANS/Algorithm-Cron-0.10.tar.gz
Algorithm::Diff 1.1903 1.201 RJBS/Algorithm-Diff-1.201.tar.gz
...
version::regex 0.9924 0.9928 LEONT/version-0.9928.tar.gz
vmsish 1.04 1.04 SHAY/perl-5.32.1.tar.gz
warnings 1.47 1.47 SHAY/perl-5.32.1.tar.gz
warnings::register 1.04 1.04 SHAY/perl-5.32.1.tar.gz
Wrote bundle file
/Users/brian/.cpan/Bundle/Snapshot_2021_03_20_00.pm
At the top of that file, there are instructions on installing it. Use the cpan from the new installation to handle this part:
package Bundle::Snapshot_2021_03_20_00;
$VERSION = '0.01';
1;
__END__
=head1 NAME
Bundle::Snapshot_2021_03_20_00 - Snapshot of installation on otter on Sat Mar 20 00:19:35 2021
=head1 SYNOPSIS
perl -MCPAN -e 'install Bundle::Snapshot_2021_03_20_00'
I hardly ever do this though. When I install a new perl and want to use a new project on it, I install the project. That project installs whatever it needs. I like the fresh start instead of carrying over stuff I might not be using anymore.
Also, note that cpan installs the latest versions of whatever you are asking for. If you need particular versions, cpanm is easier to handle. And, in that case, you might consider using a cpanfile to lock down exactly what you want.
We have a Solaris 11 system with gcc 7.3, we need to install the Ada package. On Linux gcc 7 came with the Ada/GNAT as part of the gcc install:
apt install gcc
I visited AdaCore looks like Solaris (SPARC) is not longer on the list. I need to use Ada95 and we want the same compiler on both Linux and Solaris in any case.
pkg install gcc
Only installed various C++ commands and Fortran.
pkg install gcc-ada
And variants like gcc7ada, found nothing to install.
If must, we can rebuild the Ada component of GCC 7, however I haven't found a clear cood-book style "How To ..."for that (yet).
Hopefully you can point me to these items in order of preference to help us get back-on-track.
Solaris 11 gcc-ada package for gcc7/Solaris 11 spark, and the package repository.
An 'alternative' package repository were I can retrieve the GCC Ada tooling.
Pre-build GCC 7 Ada module that we can copy to the right places.
Ready-rolled Build Ada/GNAT project for Solaris and how to download and get start building.
Instructions to download and build gcc-ada with gcc 7 on Solaris (or Unix).
From th epast few days searching about on Gnu Compiler Collection, Oracle, the package manager searches, google and so forth ... It really seems like there's next to no support for CGG Ada on Solaris these days.
I very interested in other solutions beyond that list. For instance, has anyone cross-compiled from Linux to Solaris? Would that work with GDB on the Solaris machine anyway?
Looking forward to your suggestions.
I've successfully built gcc 7.50 (x86_64 native with i386 cross-compiler) with GNAT on OpenIndiana (Hipster 2020/10) using the following procedure.
Download the bootstrap compiler from Dragonlace at http://downloads.dragonlace.net/src/ada-bootstrap.x86_64.solaris.511.tar.bz2
Get the illumos gcc 7.5.0 source from https://github.com/illumos/gcc/tree/il-7_5_0
Put the bootstrap compiler's bin directory at the front of $PATH, replace /usr/bin/gcc /usr/bin/cpp /usr/bin/g++ with symlinks to their counterparts in the bootstrap compiler directory (see note below re g++ and c++)
Make sure you've got gnu-binutils and gmake; then run contrib/download_prerequisites
Configure with
--enable-languages='c ada c++' --build=x86_64-aux-solaris2.11 --enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-nls --disable-shared --disable-lto --disable-libstdcxx-pch --enable-multilib --with-gnu-as --with-as=/usr/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld
gmake and then gmake install
NOTES:
This setup should be close enough to Solaris 11 to work. If it doesn't, try using the regular gcc 7.5.0 release rather than the illumos-modified branch.
If you get stuck at a linking stage, try using a gcc ld, but you should definitely try to use the Solaris ld first. The gnu as (gas) makes the build go much more smoothly. I didn't have any problems, but if you get stuck at the end of stage 1 or the beginning of stage 2, try setting $CONFIG_SHELL=/usr/bin/ksh -- I think it has been fixed, but at least with older gcc releases one needed to specify ksh because the built-in sh had some non-POSIX peculiarities that didn't work with some of the components' makefiles
I couldn't get one of the support libs for gnat to compile easily without building gcc c++ and using g++ with a full bootstrap. You might be able to figure it out, but the path of least resistance is likely to build gcc c++ and put the g++ symlink in /usr/bin, which is where the makefile wanted to find it.
Please note that I don't know much about Solaris, but a quick search on Google gave me the website OpenCSW. This website provides the packages gcc4ada and gcc5ada.
It appears that gcc5ada is build using a makefile (as found here, in particular notice line 424). A similar makefile exists for gcc7ada (as found here, in particular notice line 426). However, while it seems that the package "gcc7ada" can be created with the latter makefile, it is not published on the OpenCSW.org website (website is no longer updated?).
You could try to install gcc5ada first and then use this old GCC/GNAT compiler as a bootstrapper for compiling the required version (using the GCC 7 makefile).
I have successfully installed (i.e without errors or warnings) as per the instructions:
https://metacpan.org/pod/distribution/Lab-VISA/lib/Lab/VISA/Installation.pod
But when I try to run the example script I get:
Can't load 'C:/Dwimperl/perl/site/lib/auto/Lab/VISA/VISA.dll' for module
Lab::VISA: load_file:The specified module could not be found at
C:/Dwimperl/perl/lib/DynaLoader.pm line 190.
at C:/Dwimperl/perl/site/lib/Lab/VISA.pm line 11
Compilation failed in require at VISA Test.pl line 3.
BEGIN failed--compilation aborted at VISA Test.pl line 3.
Googling this suggests the there is something wrong with VISA.dll. This is generated during the install of the module, so I guess it is something in my environment. But my limited knowledge means I am not sure where to start. And I cannot seem to find a help contact or forum for Lab::VISA module.
It is mentioned in metacpan :
On 64-bit windows one needs a 32-bit version of perl with GNU binutils version <= 2.24. Otherwise linking with the NI-VISA library will fail. The reason for this are the following bugs in the GNU binutils:
binutils bug 16598
binutils bug 17910
These are fixed in the most recent version of the binutils. Once this version (2.26) is included in Strawberry Perl, it should be possible to use a 64-bit version of perl.
It is not possible to use either 32-bit or 64-bit versions of Strawberry Perl 5.22 as this version uses binutils 2.25.
So if you have WIN 64 , you need to install binutils
binutils bug 16598 : https://sourceware.org/bugzilla/show_bug.cgi?id=16598
and binutils bug 17910 : https://sourceware.org/bugzilla/show_bug.cgi?id=17910
Notice : don't forget to always read documentations
I've seen two threads similar to my question, neither with an answer that helps me.
I have been given a new laptop running Windows 7 Enterprise SP1 64-bit, on which I've installed Active Perl 5 'version 20, subversion 2 (v5.20.2) built for MSWin32-x64-multi-thread' and Microsoft Visual Studio Express 2015.
Both 'C:\perl64' and 'c:\program files (32)\Microsoft Visual Studio 14.0\VC\bin' are in my system path [without the single quotes, of course] and if I run nmake on the command line without any arguments and without a makefile in the pwd I get back the following message, definitely indicating that nmake can be found:
Microsoft (R) Program Maintenance Utility Version 14.00.23026.0
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1064: MAKEFILE not found and no target specified
Stop.
So far, so good. Now, when I run Makefile.PL to start installing a new package, I get the following message:
It looks like you don't have either nmake.exe or dmake.exe on your
PATH, so you will not be able to execute the commands from a Makefile.
You can install dmake.exe with the Perl Package Manager by running:
ppm install dmake
Checking if your kit is complete... Looks good Generating a
dmake-style Makefile
What I don't understand and would like to resolve is why Perl does not see the nmake in my PATH environment? I've installed this same package previously on a number of different machines in the past - the only real variation in any of these has been in the version number of Perl and MSVS release and the bit-version of Perl [in almost all cases I've been working 32-bit instead of 64], but I don't see why either of these would make a difference to Perl not recognizing the MSVS bin directory in my %PATH%
Installing dmake or minGW is not a solution for me: I've already done both and get a series of errors I've never experienced before with this package, so I'd really like to find a solution that would allow me to use nmake - if I still get errors afterwards, I'll work those out when I get to them.
Thanks
Edit C:\Perl64\lib\ExtUtils\MakeMaker.pm and add "require Module::Build;" before "require Exporter;" line. The top should now look something like this:
# $Id$
package ExtUtils::MakeMaker;
use strict;
BEGIN {require 5.006;}
require Module::Build; # THIS IS ADDED
require Exporter;
use ExtUtils::MakeMaker::Config;
use ExtUtils::MakeMaker::version; # ensure we always have our fake version.pm
use Carp;
use File::Path;
That fixed it for me.
I have a HostGator VPS server, and want to be able to run pdftotext, part of xpdf (http://www.foolabs.com/xpdf/download.html).
After testing this out on my Mac, it worked fine, so I went to installing it on my VPS server.
I followed the installation instructions and it all isntalled flawlessly:
Copy the executables (xpdf, pdftotext, etc.) to to /usr/local/bin.
Copy the man pages (*.1 and *.5) to /usr/local/man/man1 and /usr/local/man/man5.
Copy the sample-xpdfrc file to /usr/local/etc/xpdfrc
Then I tested it out:
root#*** [~]# pdftotext
pdftotext: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by pdftotext)
So as you can see, it couldn't find /lib64/libc.so.6. /lib64/libc.so.6 is there, however, as shown by this:
root#*** [~]# /lib64/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-52).
Compiled on a Linux 2.6.9 system on 2012-03-19.
Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
GNU libio by Per Bothner
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
I then contacted HostGator, where they told me that it will not work on my server, as it can't find /lib64/libc.so.6, and is therefor not available on Centos 6 64bit.
If this is indeed true, are there any alternatives to pdftotext that do a simple and fast conversion that would work on this server? Is it possible that the pdftotext can be complied for a different version, or that I installed it incorrectly with permissions?
Neither of these commands will work:
yum install xpdf
yum install poppler-utils
xpdf will install poppler-utils anyway and this will result in this pdftotext
pdftotext version 0.26.5
Copyright 2005-2014 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
This is not the version you want. You want this one:
pdftotext version 4.03 [www.xpdfreader.com]
Copyright 1996-2021 Glyph & Cog, LLC
This will require going to www.xpdfreader.com and then clicking on "Download". Use the latest versions from this page to set up the newer pdftotext command.
I actually compiled the sources myself:
cd /tmp
wget https://dl.xpdfreader.com/xpdf-4.03.tar.gz
tar -xf xpdf-4.03.tar.gz
cd xpdf-4.03
mkdir build
cmake -DCMAKE_BUILD_TYPE=Release
If successful you should see:
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/xpdf-4.03
Then just type:
make
It should end with:
[100%] Built target pdftotext
Then type
make install
Now when you type pdftotext you should see:
pdftotext version 4.03 [www.xpdfreader.com]
Copyright 1996-2021 Glyph & Cog, LLC
Note: I wrote all my code for pdftotext version 4.03. Took me a while to realise 4.03 and 0.26 produce vastly different results.