I just spent 6 hours tracking down a warning in the latest mod_perl2 build ... a warning for something that neither I nor any employer of mine will never use. Why? It's my contribution. If mod_perl didn't exist, I would not have a job. In case you missed that, let me repeat it:

Without mod_perl, Apache, Perl, CPAN, and tons of other stuff, I would not have a job.

It's my payment for the hundreds of thousands of manhours that went into mod_perl. It's the way I give back for a product that is the preeminent product in its sphere.

Let me say this another way - you are the recipient of over 10,000,000 manhours of design, development, testing, retesting, refining, and tuning. For free. (There are almost that many manhours again devoted to the serious modules on CPAN. Just think about that.)

But, it's not completely free. The cost is your time and your expertise. You are using modules on platforms I simply cannot access. I need you and your OS. I need your testing time. I need your patches.

Don't give up. Take the time to at least submit the results of your tests. Just something like: make test > bugreport &2> bugreport; mail owner@isp.com < bugreport

Hit Enter and work in another window. That's all we ask.

If I could ++ more than once, I would. Many, many times. This is the essence of the Open Source developer community, summed up in a few short paragraphs (and mostly the last two drive the point home).

If you're a developer, are using some other developer's work to do yours, and that developer is open to suggestions (i.e. that developer is not a big closed box like many corporations are), invest a few minutes in giving your feedback, suggestions or bug reports to that developer. If I had any public projects or modules, that's what I would like for others to do with my work. And that's why I do it with others' projects I use, as much as I can.

<humbled>Yes, you're right. I need to start compiling these things from source, I suppose.</humbled>

Hear, hear!

If every single one of a module's tests failed, there is probably a good reason for it (module failing to load would be my guess). This is particularly true for a popular module like HTML::Mason. Likely, this indicates that your system is setup in bizzare ways, in which case your problem isn't really Perl. The other alternative is that you're attempting to install a development version of HTML::Mason, in which case you still have other problems.

If don't think you can take the time to find out why it failed, think about this: how much time are you saving by getting that CPAN module working over coding your own solution?

From the HTML::Mason site:

Why do Mason tests fail during install?
The user that your web server runs as ("nobody" is a common choice, and the default on many systems), needs to be able to read the Mason build directory. If you are installing via CPAN as root, that directory is likely down root.cpan, which will have restrictive permissions. Try chmod'ding the build directory, or moving to a different (perhaps world-readable) build directory for the install.

Why am I getting segmentation faults (or silently failing on startup)?
There are a few known mod_perl issues that cause segmentation faults or a silent failure on the part of Apache to start itself up. Though not specific to HTML::Mason, they are worth keeping in mind:
* Are you using a dynamically-linked mod_perl?
Unfortunately, DSO mod_perl builds seem to be reliably unstable, especially under heavy traffic. Rebuild Apache with mod_perl linked statically.

How could I ever recommend this state of affairs to anyone, let alone clients?

If you dont have sufficient skill to deal with these issues, you shouldnt recommend them or yourself to your clients.

Ah, that first FAQ is a bit out of date. A while back we gave up on trying to run the tests that use a live web server during CPAN installs, and just run them for us developers.

Anyway, I can't see exactly what your complaint about this "state of affairs" is. Like most software, we are unable to guarantee that Mason will work 100% perfectly on all platforms, on all machines, under all circumstances. This is pretty much the state of _all_ software today.

I also note that I don't recall seeing a post to the Mason users list recently regarding Fedora RC1 install failures. Maybe if you went to the correct forum for help, you'd get some. If you complain on some random forum, you're less likely to get help.

These are the most widely used UNIX distributions in the open source world today (OSX Panther & Fedora Core 1) so I can't see how I have a non-standard Perl on either of them.

Coding my own solution isn't the alternative. PHP is - and I don't like to have to change but the more Perl modules fail to compile on standard UNIX platforms the more I think it wiser to go for a language which has most of what you need in the core installation.

Some modules have compiled OK but they seem to be the smaller ones like Mail::Sendmail

My point about excessive modularity is born-out, I would argue, by what appears to be a host of version headaches revolving around Apache1 and 2. The mod_perl developers seem to have had a hard time getting version 2 out, not that I belittle their efforts in any way.

I wouldn't call either of those "the most widely used UNIX distributions in the open source world today".

Looking at the Apple website we see, that that line is almost an exact quote. Let me tell you that that line is nothing more than Apple marketing lingo for 'many people own an Apple running OS X and OS X is based on a modified version of FreeBSD, therefore it must be the most widely used UNIX distribution.' Ah! But FreeBSD is not UNIX, "FreeBSD is a UN*X-like operating system" (source: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/introduction.html).

Fedora Core 1? Pah... lease! Sure, quite a few people have made the switch but there are still too many people using Slackware, Debian, Gentoo, Mandrake, etc to even come close.

OS X and Fedora are both non-standard so why *should* the defaults work? I would expect that you would have to work to get things to install in a standard way.

Exactly what type of failures are you experiencing? If you type % perl Makefile.pl && make && make test && make install and there is an error in make test, it is most likely due to the fact that there is a module dependency. Generally speaking, if you install the module dependency, and make test again, everything will clear up. This is not a problem with compilation; this is operator error -- failing to get everything in the right order.

Now, on the other hand, if you are saying that the make invariably fails on a module like GD::Graph -- which requires you to compile C code, I wonder if it's due to the platform you are using. Are there known issues with the modules you are trying to install, when you attempt compiling on a PowerPC based platform? If there are, it ísn't perls fault, but C's. There are so many C / C++ compilers out there, with so many foibles, that it is almost impossible for a programmer to create a program that will compile on every platform that is or ever will be.

---

Want to support the EFF and FSF by buying cool stuff? Click here.

These are the most widely used UNIX distributions in the open source world today (OSX Panther & Fedora Core 1)

Fedora is one of several distros with a sufficiently large install base that it's difficult to tell which is most widely used. SUSE and Mandrake and Debian for example all seem to be pretty much neck-and-neck with Fedora. (RedHat _sells_ more, but most of the sales are corporate support contracts, a small percentage of the total install base, which is much more difficult to measure.)

As for Mac OS X, yeah, a lot of people have it on their computers, but most of them installing any Perl modules. If you only count people who are familiar with *nix and use the Darwin underpinnings in any meaningful way, its install base is definitely smaller than Linux, probably smaller than any of the major Linux distros, and quite possibly smaller than FreeBSD as well.

Some modules have compiled OK but they seem to be the smaller ones like Mail::Sendmail

Mail::Sendmail is pure Perl, so if there are serious problems with your build environment, that won't matter. For example, you can install it even if you don't actually have a C compiler or if you don't have the header files for the standard C libraries or other essential things without which you can't successfully compile pretty much anything. In other words, your problem might not be a Perl problem at all, but a build environment problem, and Mail::Sendmail won't be affected because it doesn't require a build environment.

---

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

idea 1) Get gcc as your compiler. This solved 95% of my problems. After you get it, and get it working, then:

2) Compile perl with gcc. Some modules (DBI for example), prefer to be compiled with the compiler that compiled perl.

3) As noted in other replies, use perl -MCPAN and/or cpan plus. Otherwise, you will go crazy.

4) Use a newer version of perl. Modules may not play nice with older versions of perl.

These things may take you a day (or more) to get working right. Once you do, 99% of the modules will work like a charm.

good luck

But I'm using Perl 5.8.1 on 3 machines - OSX Panther, Mandrake 10 and Fedora Core 1. Modules are failing to compile on all 3 machines. These are the latest OSX and Linux versions. Everything is up-to-date.

Note that 5.8.1 was the perl that was binary incompatible.. It was incompatible to 5.8.0. That was repaired in 5.8.2. Thus I would guess that many people dont bother to test much with 5.8.1, and go straight to 5.8.2 and above. You might look to see if Fedora/OSX etc have an upgrade to 5.8.2.

C.

I used 'perl -MCPAN -e shell' on both Panther and Fedora Core. Many of the failed compilations failed on both machines. The machines also have different Apaches (1.3/OSX and 2/Fedora) so I doubt it is an Apache version issue.

I can tell you that Mac OS X installs of modules can be a little daunting, but most of the time they are doable. It sounds like you are not very comfortable with compiling and the underlying OS and utilities listed above. you need to consider this, perl is not CPAN. CPAN is a wonderful stash of great modules (perl, XS, inline C, ...) that can be used to save huge amounts of development time, make hard problems seem simple, and generally reduce the amount _YOU_ need to code -- they can come at a cost. The cost to you the programmer is that you must learn more about how your OS, compiler, and perl itself works to use them sometimes. Most module developers that post to CPAN make every effort to make the install of their modules as painless as possible. Considering how many platforms perl runs on and then multiply that by the obscene amount of other variables on the install base of those systems -- they have to offload some of the work to you. Perl, PHP, Python, Ruby, Java, C, C++ whatever you end up using to code will only allow you to stay at a low level of expertise in your OS and other utilities for varying short points of time. In my opinion, perl makes up for the offloaded work easily ten fold -- but if you do not want to learn and cope with the speedbumps, there is absolutely nothing holding you back from PHP or Ruby whatever -- is a free world out there, use what you like and are comfortable with. Just do not underestimate the amount of time CPAN and perl can save you (even with the learning curve sometimes required) -- In this world time is the most valuable commodity.


-Waswas

I have had many problems getting various modules to compile right on RH8 and 9. Mostly it had to do with their modifications to support unicode, but there's more to it than I understand. This affected more than just perl; I had a heck of a time getting apache, mod_perl, mod_php, mod_ssl, and a few others to compile correctly. I actually gave up on hoping to have all those in one server.

Since redhat dropped the ball after 9.0, I started looking around. My first experiment was to try trustix secure linux - a very stripped down distro, great for servers.

Boy was I surprised when the above configuration compiled correctly on the first try! I haven't had any trouble with perl modules either.

I'm guessing that several distros have so many "modifications" built in that they no longer resemble the standards that the various packages depend on. I'm really not trying to troll here, but this may not be a perl problem, but an OS problem.

I was having similar problems with RH9 until I discovered the magic file /etc/sysconfig/i18n. By default it sets LANG to "en_US.UTF-8", which triggers many, many unicode errors and warnings, at least with the version of perl that shipped with RH9. Get rid of the UTF-8 bit, and things may be much happier. Mine is now:

LANG="en_US"
SUPPORTED="en_US:en_US.UTF-8:en"
SYSFONT="latarcyrheb-sun16"
[download]

For temporary joy, just change $LANG in your current environment to en_US if it's set to en_US.UTF-8.

I used to feel the same way about CPAN, but either it's gotten much better, or I have a bigger pile of hammers to apply to things when they break. These days, I'm well below the threshold of frustration.

In your particular case -- are you sure you've exhausted the standard set of Fedora RPMs? I don't have a Fedora handy, but in my pile of standard RH9 RPMs, I have both perl-DBD-MySQL and mod_perl RPMs.

The module compiling problems due to Unicode implementation in RH9 were pretty much solved in FC1. That is, I have not had to mess with $LANG under FC1 to install modules, while this was necessary under RH9. There are still issues when reading SMB file systems, but Perl modules compile fine (as the poster already noted, his problem was in passing the tests, and the documentation actually provides a solution to that problem, which is due to file permissions).

As to solving the problem in the module's test suite, is there any reason not to move the files that have to be modified/written to /tmp, so that "nobody" can do this? Or have the test script change the permissions on the files? I suppose there's a portability issue here, since Windows essentially has no permissions, and the temp directory can be in various places on various systems. It seems silly to have a test suite that is doomed to failure on all 'nix systems and then put a "how to fix it" note in the docs...

Yes, that could be the crux of the matter. I'm going to try Debian via Knoppix-install-to-disk. Hopefully I'll then have a more standard installation not "Mandrake Advanced Extranet Server" with its httpd.conf split into 4 pieces with no manual.

Mandrake is not a server OS. It is a bleeding edge version of Red Hat with lots of pretty GUI stuff. Although RedHat is probably the dominent Linux server OS I find that a minimal install, rpm -e <widget> and then source installs of perl, apache, openssl, ssh etc remove almost all issues. When you do a binary install of anything you are typically linking here there and everywhere. It all works seemlessly if things are *where they are supposed to be* On RedHat/Mandrake they are not. By building your server essentially on top of a fairly naked kernel you get two benefits - stuff works and you have the latest secure versions of your server widgets. We use RH7.3, gcc 2.9x, and perl 5.6.2 and have very few issues.

One interesting misfeature of RH7.3 is the fact that many of the man dirs are missing. Here is an excerpt from our standard server setup docs:

man1 .. man9


Now because tripwire (amongst other programs tries to install into non
+-existent man directories ie man5 and man8 and redhat only has man1) 
+run this command to make sure these dirs exist.

mkdir /usr/man
perl -e 'mkdir "/usr/man/man$_" for 1..9'
ls /usr/man
man1 man2 man3 man4 man5 man6 man7 man8 man9
$

odd that some programs simply assume that manX will exist and don't do
+ a -p but.....they do.

If you don't do this now a whole lot of the software we are about to i
+ntall will partially choke. By partially choke I mean they will insta
+ll but the man pages won't. So when you man widget it won't bloody we
+ll work. Do it now. I'll wait ;-)
[download]

cheers

tachyon

I'd suggest doing a direct install of Debian.

Knoppix is a great demo. But when you do install-to-disk and then the Debian upgrade, you'll find that Knoppix has rearranged several packages to its own taste, resulting in package management issues to sort out. A straight Debian install takes a little more work, but the upgrade path is a lot cleaner.

I'd also suggest making sure that you have some old Debian hands available for your inevitable questions about why things are the way that they are. (IRC works.)

You may be frustrated by Debian too - you'd have to choose between using Debian's very out of date packages and installing everything from source. If you end up taking the second option then you're better off with Gentoo or Slackware.

My own take on this, in addition to what others have said:

If you haven't even looked at the error messages, you might be abandoning Perl without reason. It might be something really stupid or easy, an error in the first test, that led to all the other tests failing. A module will (almost) never fail all tests without a very good reason which can normally be traced easily. Maybe a permissions problem, or a web server problem, etc.

On most of the systems I have used (including many RedHat/Debian/SuSE/Slackware Linux machines, some Windows NT4/2K/XP machines, some OSX machines and even Debian running on an Alpha machine), CPAN worked almost flawlessly. On Windows, of course, I needed to do some homework to install everything needed to compile and install modules with XS code correctly. But that's to be expected. And once that was done, even modules that hadn't been tested on Windows worked.

You say OSX and Fedora are the most used Unices? I tend to disagree. Apple still has a very small share of the hardware in the world, so I can dismiss that one easily. And Fedora is, IMHO, still too young to have the following you think it has. However, since I have not tried Perl on Fedora, I cannot assume that Fedora itself is your problem. You'll have to investigate that... And do come back to report your findings here! (maybe create an account, so that we can tell it's you :-)

Anyways, whatever you decide, good luck to you. If Perl is your favourite as you say, I hope you'll try and get your stuff working instead of just using another language. I can't help but think that would be giving up too easily...

Again, good luck.

From reading the various developer mailing lists that I subscribe to, I would say that Fedora is still riding along the bleeding edge in some areas.

I recently got a chance to play with an OSX box for a few minutes (the 23" flat panel display almost sucked the plastic out of my wallet!). It looks reasonable but not particularly close to any other unix I have seen.

It should work perfectly the first time! - toma

I had a 23" Apple Cinema Display and, tell you what, it was useless since the default res, ie. the only one with any clarity, was 1600x1200 with everything half the normal viewing size. The advantage of all the Quartz Extreme rendering was completely lost since the anti-aliasing looked fuzzy at such a high res. Apparently video editors prefer this setup but for webdev I had to send it back. The replacement Formac Gallery 1900 is much better (and less than half the price) with a default 1280x1024.

There are very good reasons for the compilation failures you are seeing.

• mod_perl (and most other Apache modules for that matter) requires that the source for Apache be available. Neither Fedora or Mac OS X install the source, so your failure will be quick.
• DBD::mysql pretty much requires you to download and install by hand rather than using CPAN. Several environment variables need to set for the compile to complete. DBD::Oracle can have similar problems as well.
• HTML::Mason should be just fine on Fedora and I have it installed now. I did have some issues when it tried to install libapreq, which requires an Apache 1.3.xx to be installed. With Mac OS X, I think the problems I encountered involved libapreq, which requires the Apache source code to compile and install.

Overall, these problems are fairly common with many Apache or database related modules. Many of the issues with a mod_perl install are clearly spelled out on the mod_perl website, and several articles on Perl.com as well. I hate to say RTFM, but...

I'm sorry that you feel that your experience with Perl has been difficult. There are several places, such as this site, on the Internet that will gladly help with Perl related problems. Honestly, a simple question with the compiler failure will often get a quick answer to your problems, since many here have had to deal with the same issues, or the authors themselves may be hanging around. Hopefully, you won't give up on Perl, and instead give Perl Monks a chance.

I've been using and writing freeware for a long time. My first piece of code that I made available was an off-line reader for the BIX BBS (the Byte Information Exchange), in 1986 or so. You used an off-line reader to minimize your telco costs - connect to the BBS, download all new messages, read them off-line and write any replies, and then upload them.

These days I've authored and maintain a few modules on CPAN that are all Sybase (the database system) related. Making sure that these modules build correctly on the miriad of systems that are out there (OSes, compilers, perl versions, Sybase versions, DBI versions, etc.) is non-trivial, especially as I only have access to my home machines (linux and an aging Solaris 7 box). Perl actually makes this at least feasible by recording all the information it needed during its build in Config.pm, so that modules getting built at a later point can retrieve the correct information (compiler flags, etc).

Still, there are situations where this breaks - I've got a case at the moment where a user can't build the Sybase::BLK module under Solaris 9 with the latest version of Sybase, and I have no clue as to what the problem might be. With a bit of luck enough others in the Sybase community will try the same thing and come up with the answer, so that I can release a patch (or a new version).

So, to reiterate what others have mentioned - if something doesn't work for you, please let the owner/author know, but also search the web (google is your friend), because in all likelyhood someone else has had the same problem before you.

Michael

PHP is about as difficult to build as perl and DBI. I'm pretty confident that anonymonk's problem is that he did not build his own perl and thus his current setup is lacking critical components (typical of macperl).

I didn't mean typical of macperl. I meant typical of mac osx panther perl binaries.

At work we also try not to overuse perl modules either. I assume the reason is to spare the customer support people (who also install stuff), from jumping through too many hoops to get things working.

Having said that, we tend to cheat anyway. Our software is installed on HP-UX and AIX machines. These are luckily standard enough that we just provide a bunch of pre-compiled modules, and it *just works*. We even provide an entire perl install complete with modules for machines where perl 5 hasnt been installed (HP-UX comes with perl 4), and that also *just works*.

So, once you get the things installed, why make your customers go through it all again? Pack up a standard lib directory and give it to them.

C.

There are plenty of Windows/PPM ones, why not for various unix/linus distributions as well?

The simpile answer is that most Windows installations don't have a compiler easily available, and most *nix boxes do. If you want a binary package on a *nix system, you should probably look up whatever package manager your system provides (RPM, DEB, whatever).

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

In the case of the Sybase modules - the binaries depend too much on the type and version of the local Sybase installation, not to mention the various flavors of perl, etc.

Maintaining all of these binaries is time-consuming, and difficult. I've been tempted to do it, but each time I look at the problem I find that it creates more problems than it solves.

Michael

I have experienced failed compilations of many modules lately on both Mac OSX Panther and Fedora Core 1 (DBD::mysql, HTML::Mason, mod_perl and others)

I'm speculating here, but often when modules won't compile, especially non-pure-Perl modules, the problem is that you don't have all the development packages installed. For example, to install mod_perl you need all the Apache-related development packages, and to install DBD::mysql you need the MySQL-related development packages. As a general rule, if you intend to install any software that doesn't come with your distribution, you should install all of the development packages that do come with it. This is very likely to be your problem under Fedora. I don't know as much about OS X, but it may be related there too.

Perl was my first server-side scripting language and still my favourite. I just wish I didn't have to deal with CPAN's shortcomings. What a waste.

IMO, the greatest problem with the CPAN is that many of the modules are not Pure-perl and so they require a lot of extra things besides just Perl in order to install. In some cases this is due to limitations in Perl5; hopefully this situation will improve with Perl6. For now, though, the best advice I can offer is to install the development packages that come with your distribution. I find it's easiest to just install _all_ of them indiscrimanently, so I don't have to think about which ones I need. Using that approach, CPAN.pm works pretty well, although I've occasionally had to force install (notably, with Taint.pm) or install some dependency that for some reason CPAN.pm didn't notice was a dependency (e.g., when trying to install DateTime::Format::Mail just now I had to install Storable first, since CPAN.pm didn't realize that was needed).