Hi I've cross compiled Perl for my MIPS based router using Perl-cross.
Basic tests work, however the IO module is failing for some tests, notably io_sel.t, io_sock.t.
Using the debugger, I can see that the problem occurs (freezing) during a call to IO::Select::can_write(). The debugger freezes at line 122, the call to select(..).
My understanding of Perl's internals is limited, so am looking for advice on how to diagnose what the issue is. I'm assuming the issue is with the linking/wrapping against the c functions during the build?
In my experience, MIPS arch. has a lot of difficult issues for porting. So, I recommend pre-compiled perl binary and modules instead of manual build work.
Now Debian provides the Wheezy package that is minimum size( and stable) perl package file.
Debian's deb package file is just archived file. so, you can extract perl executable files/libraries from .deb packages and can install those to your router box.
Related
I am a very new to porting.
I was trying to port perl to a netbsd system. Since its a custom made build, we wont be able to run configure or make on the target netbsd system. So we are trying to cross-compile it in a host pc and copy the binary over target machine. And in order to do so, we have to make a makefile from scratch, since the format for the makefile in our build is different.
I have some basic doubts regarding this,
Firstly, In order to create a perl makefile for my custom build, what are the basic things will come. Such as ccflags, library paths etc.,?
There are some files like DynaLoader, uudmap.h, myConfig, Config.pm which gets generated while "make". How can i generate them using custum makefile.
How to set various library paths and what are they ?
The #INC, shows the perl search paths, how can i create it ?
Where exactly Perl modules get installed and when it happens?
A perl build normally involves building a stripped down version of perl named miniperl, which is then used extensively in the remainder of the process of building perl and the bundled modules.
There are two basic approaches to cross-compiling: to build miniperl for the target machine and build the modules, etc., there, or to build miniperl for the host and use it to build perl and modules for the target.
The WinCE port uses the latter approach; the rudimentary (last I knew, anyway) support for a -Dusecrosscompile switch to Configure uses the former.
I recommend you ask for advice and help on the perl5-porters mailing list: http://lists.perl.org/list/perl5-porters.html
And be prepared for hard work.
NetBSD's pkgsrc system has perl in it already and has the ability to generate binary packages that you can then install on a target machine.
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).
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 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.
I have an app that I pack into "binary" form using PerlApp for distribution. Since my clients want a simple install for their Win32 systems, this works very nicely.
Now a client has decided that they need to run all unit tests, like in a standard install. However, they still will not install a normal Perl.
So, I find myself in need of a way to package my unit tests for operation on my client's systems.
My first thought was that I could pack up prove in one file and pack each of my tests separately. Then ship a zip file with the appropriate structure.
A bit of research showed that Test::Harness::Straps invokes perl from the command line.
Is there an existing tool that helps with this process?
Perhaps I could use PAR::Packer's parl tool to handle invocation of my test scripts.
I'm interested in thoughts on how to apply either PAR or PerlApp, as well as any thoughts on how to approach overriding Test::Harness and friends.
Thanks.
Update: I don't have my heart set on PAR or PerlApp. Those are just the tools I am familiar with. If you have an idea or a solution that requires a different packager (such as Cava Packager), I would love to hear about it.
Update 2: tsee pointed out a great new feature in PAR that gets me close. Are there any TAP experts out there that can supply some ideas or pointers on where to look in the new Test::Harness distribution?
I'm probably not breaking big news if I tell you that PAR (and probably also perlapp) aren't meant to package the whole test suite and plethora of CPAN-module build byproducts. They're intended to package stand-alone applications or binary JAR-like module libraries.
This being said, you can add arbitrary files to a PAR archive (both to .par libraries and stand-alone .exe's) using pp's -a switch. In case of the stand-alone executable, the contents will be extracted to $ENV{PAR_TEMP}."/inc" at run-time.
That leaves you with the problem of reusing the PAR-packaged executable to run the test harness (and letting that run your executable as a "perl"). Now, I have no ready and done solution for that, but I've recently worked on making PAR-packaged executables re-useable as more-or-less general purpose perl interpreters. Two gotchas before I explain how you can use that:
Your application isn't going to magically be called "perl" and add itself to your $PATH.
The "reuse" of the application as a general purpose perl requires special options and does not currently support the normal perl options (those in perlrun). It can simply run an external perl script of your choice.
Unfortunately, the latter problem is what may kill this approach for you. Support for perl command line options is something I've been thinking about, but won't implement any time soon.
Here's the recipe how you get PAR with "reusable exe" support:
Install the newest version of PAR from CPAN.
Install the newest, developer version of PAR::Packer from CPAN (0.992_02 or 03).
Add the "--reusable" option to your pp command line.
Run your executable with the following options to run an external script "foo.pl":
./myapp --par-options --reuse foo.pl FOO-PL-OPTIONS-HERE
Unfortunately, how you're going to teach Test::Harness that "./myapp --par-options --reuse" is a perl interpreter is beyond me.
Cava Packager allows you to package test scripts with your packaged executables. This is primarily to allow you to run tests against the packaged code before distribution. However the option is there to also distribute the tests and test capability to your end users.
Note: As indicated by my name, I am affiliated with Cava Packager.