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.

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
[download]

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$
[download]

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);
  [download]

• 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";
  }
  [download]

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.

...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?

The original version ran eval to determine is APR::UUID is available, and if it was, add it to PREREQ.

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?

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.

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;