I have a new FreeBSD 9.0 installation that is having trouble installing modules that require C via CPAN. It seems to be down to cc being called without -I/usr/local/include. I've tried overriding that by starting CPAN with INC="-I/usr/local/include" - while that fixes the problem for some modules, it breaks for others as it seems to be overriding any defaults set in makefiles.
I've got another box with pretty much the same setup on it (slightly older installation, but still FreeBSD 9.0), perl -V on the old box shows that ccflags contains -I/usr/local/include, whereas it doesn't on the new box.
I'm guessing this is why CPAN is calling cc without it.
Question is, how can I configure it?
The settings used by CPAN modules come from the Config module which is part of core Perl. It records the compilation options and settings used when Perl was compiled.
For whatever reason, the person compiling Perl on your new FreeBSD 9.0 installation decided not to include -I/usr/local/include.
Fighting the settings in the Config module is hard work, as you've already discovered. On the whole, it is simplest not to fight it. If you want Perl to use /usr/local/include, then compile Perl so as to do so. You'll probably want to specify -l/usr/local/lib too.
You should check whether the versions of Perl are the same or not on your two similar systems.
If it works, your best bet is probably to add it to the ccflags entry in the file returned by
perl -E'require "Config_heavy.pl"; say $INC{"Config_heavy.pl"};'
Otherwise, there is surely a means of specifying this to ExtUtis::MakeMaker and to Module::Build installers. If so, you can set this cpan using o conf makepl_arg and o conf mbuildpl_arg. (Don't forget to commit!)
Related
I love the idea of local::lib. At least, I find it preferable to the default system-wide installs that cpan/perl defualts to in most every way. However, I'm having difficulties with modules that install XS and distribution upgrades to newer Perls. The instructions for local::lib call for adding this line to your .bashrc (or like file)
eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"
That executes arbitrary shell code, which is fine. You can see the code it executes by running
perl -I$HOME/perl5/lib/perl5 -Mlocal::lib
In my case it returns this code,
PATH="/home/ecarroll/perl5/bin${PATH:+:${PATH}}"; export PATH;
PERL5LIB="/home/ecarroll/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"; export PERL5LIB;
PERL_LOCAL_LIB_ROOT="/home/ecarroll/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"; export PERL_LOCAL_LIB_ROOT;
PERL_MB_OPT="--install_base \"/home/ecarroll/perl5\""; export PERL_MB_OPT;
PERL_MM_OPT="INSTALL_BASE=/home/ecarroll/perl5"; export PERL_MM_OPT;
In the above, we're setting the default options for the two most widely used module build systems,
MB is for Module::Build
MM is for ExtUtils::MakeMaker
We're telling those system to install to /home/ecarroll/perl5. The rest of the command sets
PERL5LIB which is used in setting #INC. The #INC variable in Perl is used to resolve calls with use.
and, PATH which prepends the bin/ directory that local::lib installs to.
So basically, install perl modules in your home directory, and look first for files installed in your home directory.
My question is what happens when you install something that has XS? In my case, I have an XS file,
/home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Class/Load/XS/XS.so
This was installed, with local::lib using an earlier version of Perl. I've since ran a Debian dist-upgrade and got a newer version of Perl (v5.36). Now a lot of utilities produce an obtuse error about this, including ones installed through the distro itself like in my case Dist::Zilla dzil which I installed with Debian's libdist-zilla-perl package.
$ dzil
XS.c: loadable library and perl binaries are mismatched (got first handshake key 0xeb00080, needed 0xeb80080)
Which is all a result of this module's XS,
perl -MClass::Load::XS -e1
XS.c: loadable library and perl binaries are mismatched (got first handshake key 0xeb00080, needed 0xeb80080)
This seems like very routine use of local::lib:
Am I using local::lib in the way intended? What else should I be doing?
How is local::lib supposed to handle XS?
Is there a way to make local::lib support multiple versions of Perl? My distro reads and writes the XS it manages to /usr/share/perl/$PERL_VERSION. This means a dist-upgrade leaves all the XS from the old version behind. It would be nice to have local::lib install not to /home/ecarroll/perl5/lib/perl5/ but instead to /home/ecarroll/perl5/lib/perl5.30/? Note the added minor version. Then at least a dist-upgrade wouldn't break the distribution.
Perl doesn't maintain ABI compatibility between versions. (5.34.x -> 5.36.y, for example.) After installing a new version of Perl, you will need to re-install modules that install themselves in arch dirs (XS modules and a few others). Might be easiest and safest to remove (rename) the local lib directory (/home/ecarroll/perl5) and start from scratch.
That's why I avoid using anything but distro-provided modules with distro-provided perl. The package manager ensures you always have compatible builds of the modules.
If that's not good enough, I recommend installing your own builds of perl instead of using local::lib. Tools like perlbrew makes this easy. You'll still have to re-install all the modules when you install a new perl, but you'll get the cleaner "Can't locate" error message if you forget one.
I rarely use local::lib, but I'm also a minimalist when it comes to administration. The more layers you have, the worse things get. As you see, you're own answer (now deleted) proposes even more complexity to deal with complexity that isn't likely appropriate for your situation.
But, local::lib has a way to set the locations of everything. You are trying to use the same location for everything instead of changing the locations based on what you are trying to do. However, even though local::lib lets you do that, you're likely to forget to switch things up.
My solution is simpler. I merely install a perl for whatever I'm doing (or reuse a suitable perl). I don't change the default locations at all. I never have to manage that. I simply call the perl I want:
$ ls -d /usr/local/perls/*
/usr/local/perls/perl-5.10.1 /usr/local/perls/perl-5.24.3 /usr/local/perls/perl-5.32.0
/usr/local/perls/perl-5.12.5 /usr/local/perls/perl-5.26.1 /usr/local/perls/perl-5.32.1
/usr/local/perls/perl-5.14.4 /usr/local/perls/perl-5.26.2 /usr/local/perls/perl-5.34.0
/usr/local/perls/perl-5.16.3 /usr/local/perls/perl-5.28.0 /usr/local/perls/perl-5.34.1
/usr/local/perls/perl-5.18.4 /usr/local/perls/perl-5.30.0 /usr/local/perls/perl-5.35.11
/usr/local/perls/perl-5.20.3 /usr/local/perls/perl-5.30.1 /usr/local/perls/perl-5.36.0
/usr/local/perls/perl-5.22.4 /usr/local/perls/perl-5.30.2 /usr/local/perls/perl-5.8.9
I have various symlinks and stable path adjustments to I use the tool name and the version tag I gave it:
% cpan5.36.0 ...
% cpan5.32.1 ...
People use all sorts of tools such as perlbrew, plenv, and now some other tool that you think might solve it. It's a big red flag if you have to constantly create new tools to deal with the tools that you are using. I'd rather spend my time doing something else.
I stand by my other answer—this is too much complexity and you should reduce that. But, lets work with that constraint. You want to use local::lib.
The problem is that you are trying to force the same set of modules on any particular perl, no matter how it was compiled. As ikegami explained, you can't assume that two different perls, or the same library compiled with different perls, are compatible. The version of the perls does not matter. Two different perl5.36, or any version, can be incompatible with each other.
But local::lib gives you what you need to set the appropriate values. The module itself can supply some starter values:
$ perl -I$HOME/perl5/lib/perl5 -Mlocal::lib
Attempting to create directory /Users/brian/perl5
PATH="/Users/brian/perl5/bin${PATH:+:${PATH}}"; export PATH;
PERL5LIB="/Users/brian/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"; export PERL5LIB;
PERL_LOCAL_LIB_ROOT="/Users/brian/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"; export PERL_LOCAL_LIB_ROOT;
PERL_MB_OPT="--install_base \"/Users/brian/perl5\""; export PERL_MB_OPT;
PERL_MM_OPT="INSTALL_BASE=/Users/brian/perl5"; export PERL_MM_OPT;
But, you don't need to use those values everywhere. You can have as many sets of those variables as you like. You can have a different set for every project, every perl, or however you want to organize it. The only trick is how you select the right set.
The synopsis of local::lib indicates that it expects you to set the appropriate value for your project:
use FindBin;
use local::lib "$FindBin::Bin/../support"; # app-local support library
Knowing that, you can have your per-version libraries by adding $^V in the path you give to local::lib (still with the binary incompatibility problems):
use FindBin;
use local::lib "/my/modules/$^V";
I'm using perlbrew to run a local perl in my home directory, and cpan to install new modules. However, I seem to have something configured wrong. When I use cpan it always installs libraries to the ~/perl directory, but my perlbrew is located in ~/perl5 directory. This is causing some issue with creating appropriate PERL5LIB directory, rather I should include perl or perl5 libs and in what order. I seem to keep running into chicken and the egg problem where including either first results in loading a wrong module or complaints about the wrong version used. Specifically it complains that the 5.8.8 perl version (first I installed before deciding to upgrade to a slightly-less-ancient version, and still the version of /bin/perl) conflicts with the 10.1 libraries I'm using.
I figure this can likely be fixed by updating configuration files, but I'm not sure what to change. I look at my cpan config.pm and I don't see anything defining installation direction, in fact I'm not sure how cpan knows to install locally rather then trying to install to the global cpan directory.
Can anyone point me to the appropriate configuration values I need to change to get cpan to update my perlbrew library, rather then getting two separate libraries?
Edit
Okay I'm very blind. The answer was right in my configuration file at ~/.cpan/CPAN/MyConfig.pm. I swear I looked at the file a few times, even doing a search for the word perl to hunt down any line that may point to my ~/perl directory, and yet somehow missed the blindingly obvious configuration option I was looking for...not sure how.
Anyways, once I saw it I just had to change where it pointed, which took a little trial in error. I changed this line:
'makepl_arg' => q[PREFIX=~/perl],
to
'makepl_arg' => q[PREFIX=~/perl5/perlbrew/perls/perl-5.10.1/],
which of course is the location of the perl version I'm using for perlbrew. This appears to fix my problem, and should have been easy if I wasn't blind.
I do have one annoyance, I have both this line and my PERL5LIB variables, set in ~/.bashrc, effectively hard coded to point to the perl-5.10.1 version of perllib, meaning if I decide to switch to another perl version I would need to update both references or have issues again. I'm not sure how to make cpan, or my PERL5Lib for that matter, know to infer which version of perl from the perls directory it should use. That's not too big of a problem to me, I don't think I'll be allowed to upgrade past 5.10.1 (even though I want to) so it's unlikely I'll ever change this value. Otherwise it works fine now.
Two problems.
Your CPAN is partially configured overriding the location at which it should install modules. Remove this override by clearing makepl_arg.
From within cpan:
o conf makepl_arg ""
o conf commit
From sh:
echo -e -n 'o conf makepl_arg ""\no conf commit\n' | cpan
Your PERL5LIB is telling your perl to look for modules where it shouldn't. Unset it by removing the instruction that sets it in ~/.bashrc.
You may have other problems, but we'd need to know the output of the following sh command to know for sure:
set | grep ^PERL ; echo 'o conf' | cpan | grep 'makepl_\|make_\|mbuild_'
I'm trying to install the YAML::Syck module (I'm actually trying to install Date::Manip, this is just a dependency), but it fails with the following message:
This module requires a C compiler at Makefile.PL line 38.
This happens whether I try to install using CPAN or if I try to download the packages and install manually.
I have gcc installed and on my PATH, I can access it from the same CYGWIN shell window that I'm trying to use to install YAML::Syck.
When looking for a C compiler, ExtUtils::MakeMaker and Module::Build don't necessarily look for gcc in your PATH, but query your perl's configuration for the C compiler it has been built with and expects it to be available for building Perl extensions as well.
On my system, it will look for cc in PATH, as per
$ perl -MConfig -E'say $Config{cc}'
cc
I've had trouble in the past getting everything to "just work" with cygwin, when it comes to compiling modules. You might want to take a look at Strawberry Perl, which is a Windows Perl distribution that comes bundled with all of the components needed for compilation of XS modules. I haven't personally tried to install YAML::Syck with it, but I have installed many other XS modules without incident.
Once it is installed and in your path (usually automatically), you should be able to run cpan from the Windows command prompt to install the module.
Maintainer speaking
The better forum to ask is the cygwin mailinglist. There you will find the same questions being asked again and again, we can point to the messages, and the
maintainers are present.
The quality of the answers will be much better.
The official latest perl announcement was http://sourceware.org/ml/cygwin-announce/2012-07/msg00011.html
perl used to bundle most useful modules for CPAN and Testing with the core perl.
With the latest 5.14 package the useful modules were moved to the seperate package perl_vendor.
The dependencies to be able to compile modules by your own via cpan are not included.
You'll need make and gcc-4 at least.
See /usr/share/doc/Cygwin/perl.README for the package specific README.
YAML::Syck is considered broken and unmaintained (*_why* left), please try to use a better YAML package, like YAML or YAML::XS, written by the inventor and author of YAML itself (ingy).
Date::Manip does not require YAML::Syck. cpan does like to have a YAML modules, but prefers YAML::XS.
You'll find out that you'll be able to install much more packages with cygwin perl than with strawberry perl (=mingw).
I'm using DBI and DBD::SQLite, and now I'd like to use the R*Tree feature of SQLite. Since this feature is not compiled by DBD::SQLite by default, I have to add a -DSQLITE_ENABLE_RTREE=1 to the #CC_DEFINE variable in DBD::SQLite's Makefile.PL. If I do a 'perl Makefile.PL && make && make install', everything works fine locally on my machine, but this ultimately needs to be deployable/distributable to end users.
What should I do in a case like this? Should I copy the source, grep the source, and create a DBD::SQLite::WithRTree? Create a private version of DBD::SQLite 1.31.1 (Where 1.31 is the current version of DBD::SQLite)? Perhaps a better way altogether?
All other distributions in the project are deployed/distributed via a non-public CPAN::Mini mirror + CPAN::Mini::Inject.
I have to add a '-DSQLITE_ENABLE_RTREE=1' to the #CC_DEFINE variable in DBD::SQLite's Makefile.PL
You're doing this wrong, perl Makefile.PL DEFINE='-DSQLITE_ENABLE_RTREE=1' works. This is documented in ExtUtils::MakeMaker. Now that you know that, a simple solution involving Distroprefs will likely fall in place.
For similar problems, I have installed the modified distribution in a separate directory (without changing any module names), and using use lib qw(the/special/directory) or setting $PERL5LIB for scripts that need to use the enhanced module.
Tweaking the name of the module would also do the job, but that sound like a lot more work to make and test.
You can do this:
cpan
o conf makepl_arg "DEFINE='-DSQLITE_ENABLE_RTREE=1'"
o conf commit
CPAN will then permanently add that DEFINE to the front of all your Makefile.PL calls.
So, it should just be
cpan DBD::SQLite
And your makefile options should get stuffed onto your compile lines
I want to use Apple's or RedHat's built-in Apache but I want to use Perl 5.10 and mod_perl. What's the least intrusive way to accomplish this? I want the advantage of free security patching for the vendor's Apache, dav, php, etc., but I care a lot about which version of Perl I use and what's in my #INC path. I don't mind compiling my own mod_perl.
Build your version of Perl 5.10 following any special instructions from the mod_perl documentation. Tell Perl configurator to install in some non-standard place, like /usr/local/perl/5.10.0
Use the instructions to build a shared library (or dynamic, or .so) mod_perl against your distribution's Apache, but make sure you run the Makefile.PL using your version of perl:
/usr/local/perl/5.10.0/bin/perl Makefile.PL APXS=/usr/bin/apxs
Install and configure mod_perl like normal.
It may be helpful, after step one, to change your path so you don't accidentially get confused about which version of Perl you're using:
export PATH=/usr/local/perl/5.10.0/bin:$PATH
You'll want to look into mod_so
I've done this before. It wasn't pretty, but it worked, especially since vendor perl's are usually 2-3 years old.
I started with making my own perl RPM that installed perl into a different location, like /opt/. This was pretty straight forward. I mostly started with this because I didn't want the system utilities that used perl to break when I upgraded/installed new modules. I had to modify all my scripts to specify #!/opt/bin/perl at the top and sometimes I even played with the path to make sure my perl came first.
Next, I grabbed a mod_perl source RPM and modified it to use my /opt/bin/perl instead of /usr/bin/perl. I don't have access to the changes I made, since it was at a different gig. It took me a bit of playing around to get it.
It did work, but I'm not an RPM wizard, so dependency checking didn't work out so well. For example, I could uninstall my custom RPM and break everything. It wasn't a big deal for me, so I moved on.
I was also mixing RPM's with CPAN installs of modules (did I mention we built our own custom CPAN mirror with our own code?). This was a bit fragile too. Again, I didn't have the resources (ie, time) to figure out how to bend cpan2rpm to use my perl and not cause RPM conflicts.
If I had it all to do again, I would make a custom 5.10 perl RPM and just replace the system perl. Then I would use cpan2rpm to create the RPM packages I needed for my software and compile my own mod_perl RPM.