I'm running 64-bit Solaris 10, and I have self-compiled Perl 5.10 and Postgresql 8.4.1 installed in /usr/local, both 64 bits. Solaris came with 32-bit Postgresql 8.1.4 installed in /usr, but it is not running. When I attempt to install DBD::Pg, it hits a problem because the libpq.so it finds is the 32-bit one in /usr/lib rather than the 64-bit one in /usr/local/pgsql/lib.
# /usr/local/bin/cpanp -i DBD::Pg
Installing DBD::Pg (2.15.1)
...
ld: fatal: file /usr/lib/libpq.so: wrong ELF class: ELFCLASS32
My first thought was to remove the bundled Postgres, but I've read advice against that. I'm sure everything would work if I started over with 32-bit Perl, but I'd prefer to stick with what I have.
I noticed in the CPAN output that the makefile sets LD_RUN_PATH=/usr/lib prior to linking. That seems like something that should change, but I don't know how to change it (since it's all automated by CPAN), and I don't know what other side effects such a change might have. It looks like the correct directory, /usr/local/pgsql/lib, isn't on the path at all, so maybe just making that visible would resolve the problem even without hiding the 32-bit version, but I don't know how to do that, either.
How can I get this module compiled in the environment I have, or how can I change my environment so the module will compile as-is?
From http://cpansearch.perl.org/src/TURNSTEP/DBD-Pg-2.15.1/Makefile.PL
In brief:
By default Makefile.PL uses App::Info to find the location of the
PostgreSQL library and include directories. However, if you want to
control it yourself, define the environment variables POSTGRES_INCLUDE
and POSTGRES_LIB, or define just POSTGRES_HOME. Note that if you have
compiled PostgreSQL with SSL support, you must define the POSTGRES_LIB
environment variable and add "-lssl" to it, like this:
export POSTGRES_LIB="/usr/local/pgsql/lib -lssl"
Related
I have installed Debian 10 in order to migrate a web server from one machine to this Debian 10 machine. The web server built on apache2 needs mod_perl. The module was not found on the new machine, so I installed perl5.28 (and mod_perl.so has been added). But now it seems there is a mismatch between a previous perl version (5.20) and the latest one (5.28). I use the perl binary correspondint to v5.28, #INC contains directories related to v5.28 (according to "env -i perl -V"). But when I try to start the apache2 server, I get this error: "apache2: Perl lib version (5.28.1) doesn't match executable '/usr/sbin/apache2' version (5.20.2)". Can anyone help? Thanks a ton in advance.
When you built apache with mod_perl, you used v5.20, but it seems that's not around anymore. Different versions of Perl are not guaranteed (or even attempt to be) binary compatible. Between Perl versions, you'll likely have to re-compile all XS modules, too.
You need to recompile apache with the Perl that you want to use, or install the Perl that apache wants to use. This time you may want to statically compile mod_perl into apache.
This problem isn't specific to Perl, though. Many software libraries will complain similarly when you replace the library they compiled against.
I have installed a perl module, say XYZ then a folder is created that contains many .pm files. I copied the folder and put it in any other system where XYZ is not installed. So, I'm able to use methods of XYZ module in both system. I mean, I'm unable to find out the difference between these method, but I think there must be some. What I know is, when we install a perl module then dependencies also gets installed. Am I right? Can anyone mention other difference between two, if any?
A few off the top of my head:
In case of an XS module, the code is compiled for the local platform.
Installing a module via cpan usually runs the test suite so if there is any other reason beyond dependencies why it wouldn't work, you're told so (I guess that's very rare though)
Regular installation automatically goes to a directory where your perl can find modules.
Of course you can take care of all these yourself. These days chances are pretty good you're running either Linux or Windows on something x86-ish and as long as you only copy Linux to Linux and Windows to Windows, and to the same place as on the source system, you'll be fine. Basically that's what binary Linux distributions and ActivePerl packages do, too, and it may make sense e.g. if you want to avoid installing a whole bunch of compile-time dependencies on all target systems. Just make sure you don't get yourself into a mess by writing to system directories (e.g. /usr/share/perl5) that are supposed to be managed by your system's package manager.
I’m a mere mortal using Cygwin on Win7 and wanting to develop perl scripts using SOAP::lite. Installation instructions I found at soaplite.com directed me to start with perl –MCPAN –e shell before attempting an > install SOAP::lite
The newb in me didn’t appreciate that my windows user profile has a space character in it and the CPAN set-up seemed to go all horribly wrong around the point where the script was writing make files for local::lib, MYMETA.yml and MYYMETA.json. I got “no such file or directory” messages quoting only the portion of the path that followed the space in my user profile.
$ uname -a
CYGWIN_NT-6.1 UKLHRL00020 2.0.4(0.287/5/3) 2015-06-09 12:22 x86_64 Cygwin
$ cpan --version
Loading internal null logger. Install Log::Log4perl for logging messages
/usr/bin/cpan version 1.61 calling Getopt::Std::getopts (version 1.06 [paranoid]),
running under Perl version 5.14.4.
[Now continuing due to backward compatibility and excessive paranoia.
See ``perldoc Getopt::Std'' about $Getopt::Std::STANDARD_HELP_VERSION.]
Nothing to install!
When I ran perl –MCPAN –e shell for the first time, it did report “Warning: You do not have write permission for Perl library directories.” and I elected for the default option [local::lib] for the approach to be taken.
So what can I do next?
Looking closer at the Cygwin’s setup-x86_64.exe, a search for “cpan” lists eight packages under the perl category for perl-CPAN-* and perl-Parse-CPAN*, which are all set to “Skip”. The package perl-CPANMeta: Perl distribution CPAN-Meta is version 2.150001-1 from cygwin.mirrors.pair.com. Since this is not installed yet, but the installed Perl5 has some knowledge of an old CPAN, I need to know if it is safe to install the latest and will it work with a space in my profile? Do I need to remove the old CPAN, and how?
You probably want to update to the latest version of ExtUtils::MakeMaker, recent versions contain various fixes for paths containing spaces. This should fix these issues.
I'm trying to build DBD::Pg on a linux host via the Makefile.PL; my requirements are such that I must be able to dynamically link against perl, but statically link against libpq.so (since it may not be available on all boxes).
Is there an easy way to do this? I have tried changing the link options in the LIBS directive of the Makefile.PL but MakeMaker ignores my options.
IMO you've mis-specified your requirements.
You do not need to statically link to libpq just because it might not be available on all systems.
What you should generally do instead is dynamically link to libq and either set LD_LIBRARY_PATH in a wrapper script or use rpath linking so that libpq can be found.
Be aware though that whether statically or dynamically linking, if some other module loads a libpq into the same Perl you'll either get two incompatible libpqs linked into the same executable (boom) or one of the modules using a libpq other than the one it was compiled against (also boom). If you use rpath linking, ld.so's awareness of link scopes might let you get away with it, but setting LD_LIBRARY_PATH will almost certainly cause issues.
You might want to look into using rpath with $ORIGIN.
Unfortunately, trying to do static linking of libpq is not likely to solve your problem at large.
libpq itself is likely to depend on libc (glibc). If you link it statically, but other modules dynamically, it means you will have 2 copies of libc: one inside libpq, another referenced by Perl itself and loaded dynamically. This is very dangerous situation, especially if some procedure allocates memory using malloc and passes pointer back to caller. If you have memory allocated by malloc from one copy of libc, but freeed by another copy, your program (and Perl) will definitely crash.
In other words, if you want to go static, you must go all way through - everything, 100% must be compiled statically, so only one copy of libc used by your application. And the opposite is true - if you are dynamic, everything should be dynamic, as to only ever use one copy of libc. These rules don't apply only if your libraries do not use anything from libc (not even sprintf).
Even if you succeed at static libpq compilation and it will work (not very likely), what if DBI is not installed? I have seen enough Linux boxes where DBI is not present by default. Do you compile DBI statically then as well? What if Perl is not present (as unlikely this is on Linux), or if it is very old?
Proper solution is to install it using native OS package manager:
sudo apt-get install libdbd-pg-perl # Ubuntu/Debian
sudo yum install perl-DBD-Pg # Redhat/Fedora
If you do not have root on hosts in question, maybe you should consider using perlbrew - install your own Perl in home directory. With this, you should be able to compile your own copy of libpq and link it with Perl provided by perlbrew dynamically.
I compile the perl DBI package on solaris 10 say SERVER1 with say perl 5.8.10 installed on it and create DBI.
Now I copy the above DBI.so and the DBI.pm files to another solaris SERVER2 machine with the same hardware and the same version of perl.
Can I be sure that the DBI package will run smoothly and I will not get any run-time errors in future ?
Please note that I dont have the flexibilty to install a C compiler SERVER2.
Hardware does not matter so much as you think, the operating system abstracts this away nicely. For binary compatibility, the minor version must match, so the other Perl must also be from the 5.8 series. (By the way, 5.8.9 was the last one, 5.8.10 does not exist.)
As you're talking about a dynamic library, the integration on the C level is much more important. Are the libraries referenced from the DBI.so compatible (e.g. libc.so has the same version on both machines)? Check with the ldd command.
In case of mismatches, you will not get run-time errors, but very obvious crashes at compile time when perl attempt to load DBI.
The answer is the same as in this question: How can I install Perl modules on a restricted server? -- install your modules and libraries on a system with the same architecture (using a special installation directory), then copy the modules over to your restricted system.
You'll need a C compiler somewhere (unless you can find pre-compiled binaries of the .so or .dll files you need), but it doesn't have to be on the intended target.