I am newbie to perl cross compilation.
I'm trying to install perl from source as given in www.perl.org.
Commands followed are ./Configure, Make, Make test.
To find the path for specific installation, the CLI "perl -V" shows error as follows.
# ./perl -V
Can't locate Config.pm in #INC (#INC contains: /usr/local/lib/perl5/5.9 .).
BEGIN failed--compilation aborted.
I think i have done some mistake in path inclusions.
Please let me know the reason and solution for successfull cross compilation.
Thanks in advance.
It's probably possible to cross-compile Perl (building on Linux and targeting for BSD), but there's not much point in doing so. NetBSD is as capable as Linux of building Perl locally, and that's almost certainly what you should do.
You can build it from source, following the installation instructions, or better yet you can install a binary package, since somebody else has already done the work of building Perl from source for you.
Unless you have a very specific requirement for an old version, you should install the most recent production version, which I believe is 5.14.2.
You mentioned in a comment that when you build Perl from source on your target BSD machine, Make test had 2 failures. You had a 99.86% success rate. Surely that's good enough -- and you're not likely to do any better by cross-compiling. You might want to look into those failures and the LD_LIBRARY_PATH issue (I don't know what it should be set to for NetBSD), but those issues aren't so serious that you should give up and use a radically different approach.
Related
I'm trying (desperately) to build / install the newest version of WWW::Curl onto my activeperl box (I'll explain in a moment why I don't use the PPM)
I had to make some modifications as per the instructions found here:
http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/README.Win32
I also had to change the following line:
From:
open(H_IN, "-|" "gcc", "$curl_h") and $has_cpp++;
To:
open(H_IN, "gcc $curl_h") and $has_cpp++;
I finally got perl Makefile.PL to work but now, when I run nmake, I get the following:
Missing right curly or square bracket at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
NMAKE: fatal error U1077: 'C;|windows\system32\cmd.exe' : return code '0xff'
Stop.
Now, the reason I'm trying to compile this rather than using the PPM supplied by u.winnipeg is because the that PPM doesn't seem to support SSL transaction (I get "libcurl: ssl disabled") Now, if anyone can show me how to get ssl to run on this PPM, I'm more than happy to use it.
Thank you very much in advance
I presume the original was
open(H_IN, "-|", "gcc", "$curl_h")
The reason you have to change that in because noone got around to implementing feature in Windows. Change it to
open(H_IN, qq{gcc "$curl_h" |})
Use the right name and syntax for your compiler.
Well, I finally figured it out, thanks to everyone who responded. There were a bunch of things I had to change.
Using http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/README.Win32 as a guide:
The open cmd as I did above worked fine. However, I did use the advice returned by ikegami, reinierpost, and mob.
Using nmake /n (as advised by socket puppet), it printed out all of the perl statements which were being executed. I took this output and placed it into a .bat file and corrected the perl syntax.
I changed all instances of
pm_to_blib({{#ARGV}
to
pm_to_blib({#ARGV}
(it is disturbing these were returned)
Then, I had to link the libcurl libraries to each line instantiating g++, which were not linked correctly. After I added these references, everything else went smoothly.
These were added:
C:\lc\curl\lib\libcurl.a C:\lc\curl\lib\libcurldll.a
Now, WWW::Curl is happily running on my system.
As for using the PPM version, it is exactly because of SSL I had to upgrade. The newest version of WWW::Curl is 4.15 the ppm version is (I believe) 3.02.
First, many people don't know that you can use ppm to install MinGW to use cpan to install modules.
Second, if the libcurl provided by your module doesn't do SSL, you can try and replace it with a suitable SSL version from the download page. This might well fail, but you might also be lucky.
Last night I was reading about a mysql tuning program here. I installed it and it said I needed a perl version higher than the one I had. I downloaded and installed perl 5.12.x
Suddenly my Munin utilities were tossing off errors like:
Can't locate RRDs.pm in #INC (#INC contains:
/usr/lib/perl5/site_perl/5.12.2/i686-linux /usr/lib/perl5/site_perl/5.12.2
/usr/lib/perl5/5.12.2/i686-linux /usr/lib/perl5/5.12.2
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at
/usr/sbin/nginx-graph.pl line 2
Uninstalling and reinstalling the rrdtool rpms didn't move RRDs.pm from /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/RRDs.pm
Thought I'd try installing rrdtool from source. It wanted pango.
Had to install newer FreeType and FontConfig.
Then the pango install wanted a new glib. Glib wouldn't make due to a gzlibcompressor error. Some Googling suggested that upgrading glib could cause a whole host of other issues.
I just want my !##$ munin graphs, but I feel like I've started sliding down a dangerous slope, especially as this is hosting my nginx webserver.
Any tips, ideas, warnings?
It appears you used to have Perl 5.8.something. Perl major releases are not binary compatible, so you have to reinstall/upgrade all modules using XS and any programs that embed the Perl interpreter when changing between 5.8.x, 5.10.x, and 5.12.x.
I would try to revert your system Perl to 5.8.x. This should get Munin working again. (I can't give detailed instructions for this, because I don't know what distribution you're using, how you installed Perl 5.12, or what else you've done trying to solve this.)
Then use perlbrew to install a newer version of Perl for your personal use without messing up things that depend on the system Perl.
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
I'm trying to setup a Perl development environment on my Mac laptop and have been having a really hard time getting it working. I thought I had everything configured correctly but when I try to run a sample script it is reporting errors with the DBI module and can't access the DB.
Here is what is reported in the Apache error logs:
[Fri Apr 30 23:11:33 2010] [error] [client 127.0.0.1] Can't locate DBI.pm in #INC (#INC contains: /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .) at main.pm line 5.
I downloaded and installed both modules manually to work with MAMP using the following commands as specified in this forum post:
For DBI
1. cd /Library/Perl/DBI-1.611
2. sudo Perl Makefile.PL
3. sudo make
4. sudo make install
For DBD
1. cd /Library/Perl/DBD-mysql-4.014
2. sudo Perl Makefile.PL --mysql_config=/Applications/MAMP/Library/bin/mysql_config
3. sudo make
4. sudo make install
What I noticed while running the above commands is that the files seems to be getting installed in the '/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/' directory which doesn't seem to be one of the search directories that Apache mentions in the error at the beginning of this post. Here is what I'm seeing during the install:
$ sudo make install
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/DBI.bundle
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/dbipport.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/DBIXS.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/dbixs_rev.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/Driver.xst
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/Driver_xst.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/TASKS.pod
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/DBM.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/File.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/Gofer.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/Changes.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/DBD.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/Profile.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/ProxyServer.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/PurePerl.pm
Installing /opt/local/share/man/man3/DBD::DBM.3pm
Installing /opt/local/share/man/man3/DBD::File.3pm
Installing /opt/local/share/man/man3/DBD::Gofer.3pm
Installing /opt/local/share/man/man3/DBI.3pm
Installing /opt/local/share/man/man3/DBI::DBD.3pm
Installing /opt/local/share/man/man3/DBI::Profile.3pm
Installing /opt/local/share/man/man3/DBI::ProxyServer.3pm
Installing /opt/local/share/man/man3/DBI::PurePerl.3pm
Installing /opt/local/share/man/man3/TASKS.3pm
Installing /opt/local/bin/dbiprof
Installing /opt/local/bin/dbiproxy
Writing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/.packlist
Appending installation info to /opt/local/lib/perl5/5.8.9/darwin-2level/perllocal.pod
My question is, what am I doing wrong and how can I either 1) Get Apache to look in the right directory where the DBD & DBI modules are installed or 2) Update the way I'm installing the module to install them into one of the search directories. I honestly don't know what option makes more sense and could use guidance on that as well.
As you can probably tell I'm pretty lost at the moment. Please help!!! Thanks in advance.
It looks like you've already installed another Perl via macports (/opt/local is where all macports installations go), and /opt/local/bin is earlier in your $PATH than the system Perl in /usr/bin. That's fine, if you are happy running Perl 5.8.9 rather than Perl 5.10.0 (hint: if you aren't sure of the differences, then the differences don't matter).
It's usually advised to not make extra installations to the system Perl. Apple may upgrade components through regular system updates, which could interfere with any modifications you have made, and if you make a mistake with an installation, it's difficult to remedy it without doing a full system reinstallation or having some serious understanding of the operating system guts. So, since you've already got another Perl installation ready, I would strongly encourage you to stick with that one.
However, you probably shouldn't be manually installing libraries if there is already a distribution available on macports. I used port search dbi and port search dbd to find them: the distributions are named p5-dbi and p5-dbd-mysql. You can install those like any other macports module: with sudo port install <distroname>. (You may need to install mod_perl itself, too.)
After that, you simply need to tell Apache/mod_perl to use that Perl installation rather than the system perl. I've never done that, so I can't advise on the best way to do it. However, quick searches on http://superuser.com suggest that the macports version of apache will run by default (via the same $PATH ordering), so I'd just Try It And See :).
Great answer, Ether. Having done this far too many times to count, I can give you a few pieces of advice:
Note: I am apparently limited to a single link in the post, so I had to remove all of my annotations. Thankfully, there is Delicious where I've stored them all with a stackoverflowmacports tag. Any place below where I removed a link to fit under Stack Overflow's ridiculous anti-spam measure, I've marked it with (*).
If having a reliably-working development environment at all times is important to you, rely on as LITTLE Mac OS X bundled software as possible. I love Apple but they have absolutely no qualms about breaking custom setups of their software as often as possible.
If #1 sounds like what you need to do, Macports is an EXCELLENT choice. I used to use Fink but they got left in the dust ages ago in terms of ease of use and spectrum of available software. The easiest route to installing macports is via the binary package install method (*)
As Ether mentions, when you have everything set up correctly, the Macports-provided MySQL, PHP and Apache all work together well without the system-installed analogs interfering. Most of that has to do with your PATH setting but all of those details are handled by the package installers post-flight script (*)
Once you're on the Macports train, it should become the very first place you look for any software. port search and port info are constant companions. They've got 6863 ports (*) currently which covers MOST of your bases.
When you do need to go outside of the Macports realm to find something, install it in /usr/local. That part of the file system hierarchy is yours to play with. Don't be lulled into a false sense of security and think that because Macports doesn't have what you're installing, it's okay to put it in /opt/local because invariably that software will install some dependency that will ALSO be a dependency for some piece of Macports software down the line and Macports will not allow a port to be installed if any one of its files would overwrite an existing file not managed by Macports (unless you force it which is always bad manners)
If you do any work with Perl and you use Macports' version, you will absolutely find yourself in a situation Macports doesn't have the one CPAN module you're looking for. (And, really, given that there are two and a half billion CPAN modules, who can blame them?). This will happen often enough that you will most likely tire of the manual installation method (*) (perl Makefile.PL; make; make test; sudo make install; cha; cha; cha) and long for the ease of use you've grown accustomed to with Macports.
If so, you can absolutely use the cpan (*) utility, CPANPLUS (*) or cpanminus (*) for all of your installing needs. Just make sure to make the necessary adjustments in the configuration of your tool of choice to instruct it to install your modules into /usr/local/lib/perl5, ignoring /opt/local/bin/perl's insistence that modules go into /opt/local/lib/perl5. You can set the PERL5LIB environment variable in your shell's init scripts to additionally look in /usr/local/lib/perl5 for modules. Just grab the #INC output from perl -V and tack it on the end...
And finally... Leveraging the system's daily init scripts or third-party software like Anacron (*) or MacPorts Notifier (*) (both available through MacPorts), make sure to update your software frequently. You don't have Mother Apple protecting you with Software Updates for the Macports installed software which have just as many bugs and security exploits as the very same software Apple bundles.
By updating frequently, you'll stay ahead of the baddies and by automating it, the upgrades will actually happen and you won't end up as I have in the past with a full weekend blown because you had a mountain of outdated ports to upgrade. Note: Macports stages its updates and if it fails at any point, your current version continues to work. Apple could learn a thing or two from them, I tell ya...
So, that's all I can think of a the moment. Hopefully the lessons above will get you going quickly and save all of the time, effort and stress I've experienced in past years in learning it. I would argue it's still far better than the alternative: Hating Apple because they break all of your nice things... :-)
I had a similar problem with Apache using the wrong Perl. I fixed it by appending the following lines to my httpd.conf file:
SetEnv PATH [colon-separated list of directories]
SetEnv PERL5LIB [colon-sep'd list of directories]
In my case, it looked like this:
SetEnv PATH /opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/mysql/bin:$PATH
SetEnv PERL5LIB /opt/local/lib:/usr/local/lib
I'm currently using the PAR Packer (pp) to package a couple of pl scripts such that they can be copied to a machine and "just work" without my client having to muck with CPAN.
Unfortunately, the PAR Packer doesn't work for deep dependencies. For example, a script imports CHI::Driver::File but does not explicitly import Log::Any::Adapter::Null which CHI::Driver::File requires. PAR does not pick up this dependency and running the generated script will crash with the following error message:
Can't locate Log/Any/Adapter/Null.pm in #INC (#INC contains: CODE(0x874aab8) /tmp/par-apache/cache-7b4508ab92efb43271da1629e8eb654c1572cc55/inc/lib /tmp/par-apache/cache-7b4508ab92efb43271da1629e8eb654c1572cc55/inc CODE(0x87e8f54) CODE(0x87e9194)) at (eval 215) line 3.
Compilation failed in require at CHI/Driver/File.pm line 11.
BEGIN failed--compilation aborted at CHI/Driver/File.pm line 11.
My work-around is to explicitly import "Log::Any::Adapter::Null" but there must be a better way. Perhaps this is a bug with the PAR Packer? I have installed the latest version (0.994).
Well, have you read the documentation? It gives a number of command-line options to include dependencies, and even the option to manually force modules to be included.
If you want a stand-alone script as opposed to a stand-alone binary (which is the default mode for pp), then add the -P option. I'd advise against it, though. It's the least-tested mode of operation.
Note also that PAR::Packer DOES work for deep dependencies. The subject of your question is a bit pretentious. In fact, PAR::Packer doesn't really check any dependencies itself but delegates this to Module::ScanDeps. Now, Module::ScanDeps is a heuristic approach to dependency scanning and it can be broken by ugly fuzzing with dynamic loading of dependencies. (i.e. generating module names at run time and then using them in an eval).
Indeed, if you look at the sources for Log::Any (which is used by CHI::Driver::File), you'll quickly see that it uses dynamic loading of modules. This is why the ::Adapter::Null module isn't being picked up.
Generally, we fix these issues by adding a special case to Module::ScanDeps for such modules whose author thought it'd be a good idea to defeat any sort of static analysis. Until you get a fixed version of Module::ScanDeps, you can use the -c or -x options to pp to have the dependency resolution use compilation or execution of the program instead of only relying on static analysis. The augmented Module::ScanDeps has version 0.95 and should be available from CPAN within the day.