Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: Module compilation hell

by Notromda (Pilgrim)
on Mar 31, 2004 at 00:28 UTC ( #341157=note: print w/replies, xml ) Need Help??

in reply to Module compilation hell

I hate to say this, but it may well have to do with your choice of platforms. Hear me out on this, it's been an eye-opener for me. I don't know anything about OSX (I'd like to!) but I have become very disenchanted with anything redhat based since redhat 8.0, and I assume that fedora core is based on that tree.

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.

Replies are listed 'Best First'.
Re: Re: Module compilation hell
by sfink (Deacon) on Mar 31, 2004 at 04:56 UTC
    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"
    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...

Re: Re: Module compilation hell
by Anonymous Monk on Mar 31, 2004 at 01:01 UTC
    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 ;-)



      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://341157]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2019-07-20 06:30 GMT
Find Nodes?
    Voting Booth?

    No recent polls found