Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

ExtUtils::MakeMaker, APR::UUID or Perl problem?

by jk2addict (Chaplain)
on Dec 03, 2005 at 04:02 UTC ( #513773=perlquestion: print w/replies, xml ) Need Help??

jk2addict has asked for the wisdom of the Perl Monks concerning the following question:

Holy crap, this is a stumper. I got a report from Sean Comeau about perl Makefile.PL in Handel creating a 0 byte Makefile under perl 5.8.6, EU::MM 6.30 on OpenBSD 3.8. After a lot of queestions and tinkering, he setup ssh access for me to tinker on the machine in question. I've found the single statement that causes the problem, and I'm even more mystified what the hell is going on. Of course, all works fine in the same EU::MM version on FreeBSD/Linux.

Here's the pared down Makefile.PL. The original version ran eval to determine is APR::UUID is available, and if it was, add it to PREREQ.

use ExtUtils::MakeMaker; use 5.006; use strict; # this line causes a 0 byte Makefile eval 'use APR::UUID;'; # These doesn't work either: # eval 'require APR::UUID'; # eval {require APR::UUID}; # use APR::UUID; WriteMakefile( NAME => 'Handel', VERSION_FROM => 'lib/Handel.pm', AUTHOR => 'Christopher H. Laco <claco@chrislaco.com>', ABSTRACT => 'Simple ecommerce framework with AxKit support', PREREQ_PM => { 'Class::DBI' => '0.96', 'DBI' => '1.36', 'Error' => '0.14', 'Locale::Maketext' => '1.06', 'Module::Pluggable' => '2.95', 'Path::Class' => '0', }, (ExtUtils::MakeMaker->VERSION >= 6.11) ? (NO_META => 1) : (), dist => { PREOP => 'pod2text lib/Handel.pm > $(DISTVNAME)/README', }, test => { TESTS => join ' ', (glob("t/*.t"))} );

If I remove all of those problemed lines, the Makefile is generated just fine. What's going on?

To make matters stranger, this works just fine:

perl -e 'use APR::UUID;print APR::UUID->new->format;'

If there's a problem with the APR module, why in Makefile.PL and not in -e? If the lib is just crapping out, where's the error?

-=Chris

Replies are listed 'Best First'.
Re: ExtUtils::MakeMaker, APR::UUID or Perl problem?
by Ovid (Cardinal) on Dec 03, 2005 at 16:09 UTC

    This is an attempt to use a mod_perl module outside of mod_perl. APR::UUID is actually just XS code and shouldn't be used directly. You should first use APR and then you can use APR::UUID. See the mod_perl docs for more info.

    Cheers,
    Ovid

    New address of my CGI Course.

      I think that doc needs updating; with mod_perl 2.0.2, at least, the write_pm method of ModPerl::WrapXS generates a use APR (); line for every APR::* module.

      Is it just APR::UUID, or do any of the APR::* modules (that can be used outside of mod_perl) lead to such a problem? You might try running the apr-ext tests to see if these expose any problem; this can be done with an installed mod_perl by going into the mod_perl_src/t/ subdirectory and doing, for example,

      perl -T -Ilib apr-ext/uuid.t

      Negative. Using or requiring APR first (use APR; use APR::UUID;) does not fix the problem. Not using APR at all isn't a problem here, since the command line version at the end of my post works.

      Second, it works as-is on every platform except for OpenBSD. I think that's the marker of something strange going on here.

      In fact, just 'use APR;' in the Makefile.PL above causes the same problem.

      Update: I just got a copy of the mp2.0.2 source on the server in question. the uuid tests pass fine:

      test:~/mod_perl-2.0.2/t$ perl -T -Ilib apr-ext/uuid.t 1..3 # Running under perl version 5.008006 for openbsd # Current time local: Sat Dec 3 19:12:38 2005 # Current time GMT: Sat Dec 3 19:12:38 2005 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.27 ok 1 ok 2 ok 3 test:~/mod_perl-2.0.2/t$
Re: ExtUtils::MakeMaker, APR::UUID or Perl problem?
by randyk (Parson) on Dec 04, 2005 at 05:41 UTC

    Since it seems there's no problem with APR in stand-alone mode, it would be good to narrow down why it's interfering with WriteMakefile. A couple of simple possibilities come to mind that would be worth checking:

    • Somehow APR affects printing in general. Does the following work in generating a non-zero sized file?
      use APR; open(FH, '>test.txt') or die "Cannot open test.txt: $!\n"; print FH "This is some text\n"; close(FH);
    • APR somehow interferes with the arguments passed to WriteMakefile. Does the following print (to STDOUT) the named MakeMaker parameters?
      use ExtUtils::MakeMaker; use APR; my $r = WriteMakefile( NAME => 'Handel', VERSION_FROM => 'lib/Handel.pm', AUTHOR => 'Christopher H. Laco', ABSTRACT => 'Simple ecommerce framework', ); for my $key (qw(NAME VERSION_FROM AUTHOR ABSTRACT)) { print "$key -> $r->{$key}\n"; }

      First example: Succeeds. test.txt contains the text.

      Second example: Succeeds & Fails. It prints the key/value pairs to STDOUT, but the resultant Makefile is 0 bytes.

      I don't think it's just interfering with WriteMakefile, but instead either other XS loading or file writing.

      In the dist in question, I have a bunch of tests that read/write to sqlite databases using DBD::SQLite. I commented out the APR load in Makefile.PL to get a complete Makefile. Then I started running the tests.

      All of the sqlite tests were failing with strange errors, corrupt db, locked db, full db, etc. In my core module, Handel.pm, I commented out the same APR::UUID eval statement I use in Makefile.PL to find the appropriate uuid module.

      As soon as I commented out APR::UUID, all of my sqlite tests passed. If I uncomment it, they fail again.

      So, it's not just EU::MM being borked, but other things as well. I don't know enough to know whether it's effecting the loading of XS in other modules, or some read/write process being borked.

        That sounds right about it being a more global problem. One place that something specific to openbsd arises is in APR.pm, in defining the dl_load_flags sub. I'm not sure of the background behind this - probably someone on the modperl mailing list would be able to help.

        Is this Perl built with ithreads support? If so, the comment in README.openbsd of the perl sources about needing to upgrade to Perl 5.8.7 may be relevant.

Re: ExtUtils::MakeMaker, APR::UUID or Perl problem?
by PodMaster (Abbot) on Dec 04, 2005 at 04:31 UTC
    ...I've found the single statement that causes the problem, and I'm even more mystified what the hell is going on....If I remove all of those problemed lines, the Makefile is generated just fine. What's going on?
    Its simple, APR is breaking MakeMaker. How or why is a question best left to the maintainers of those modules.
    The original version ran eval to determine is APR::UUID is available, and if it was, add it to PREREQ.
    That doesn't make sense to me. If APR::UUID is a prereq, it should be listed in PREREQ_PM no matter what. If its already installed, whats the point of adding it to PREREQ_PM?
    If there's a problem with the APR module, why in Makefile.PL and not in -e? If the lib is just crapping out, where's the error?
    Because in Makefile.PL you're using MakeMaker, which is what APR breaks?

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      That doesn't make sense to me. If APR::UUID is a prereq, it should be listed in PREREQ_PM no matter what. If its already installed, whats the point of adding it to PREREQ_PM?

      It's not supposed to make sense to you. Just run the Makefile.PL.:-)

      The real answer is that the Makefile.PL requires different uuid generation module depending on the platform (win32/*nix) since there isn't on cross plaftorm module..except for APR::UUID. But I'm not going to require people to install APR just for that if they already have a one of the others installed. And if APR::UUID is available, there's no need to make any nother PREREQUS. Hense..the evals to see what is available.

Re: ExtUtils::MakeMaker, APR::UUID or Perl problem?
by Errto (Vicar) on Dec 04, 2005 at 20:58 UTC
    Just wondering...you say in one of your comments that you're using APR::UUID because it's the only cross-platform UUID generator. I'm not too familiar with this area, but it seems unnecessary if you're not writing a mod_perl application. How about Data::UUID?

      Data::UUID doesn't work on Windows. There is a patch, but its quality in terms of uuid colisions is unknown. UUID doesn't compile everywhere. There are Win32 uuid modules that are, windows only. Previously, I just used what was available on the platform. I added checks for APR::UUID because it also could create uuids if someone already had APR installed;

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://513773]
Approved by Joost
Front-paged by BrowserUk
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (1)
As of 2022-01-19 01:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (54 votes). Check out past polls.

    Notices?