in reply to Re: ExtUtils::MakeMaker, APR::UUID or Perl problem?
in thread ExtUtils::MakeMaker, APR::UUID or Perl problem?

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.

  • Comment on Re^2: ExtUtils::MakeMaker, APR::UUID or Perl problem?

Replies are listed 'Best First'.
Re^3: ExtUtils::MakeMaker, APR::UUID or Perl problem?
by randyk (Parson) on Dec 04, 2005 at 18:43 UTC

    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.

[reply]

      Assuming I'm reading this correctly, it doesn't look like thread-enabled: 

      test:~$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
  Platform:
    osname=openbsd, osvers=3.8, archname=i386-openbsd
    uname='openbsd'
    config_args='-dsE -Dopenbsd_distribution=defined'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultipl
+icity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef

      [download]
[reply]
[d/l]

      Even stranger. If I save a copy of that APR.pm into the dists lib and do perl -Ilib Makefile.PL, I still get a 0 byte Makefile. Now, if I add this to that APR.pm: 

      BEGIN {warn 'using custom APR'};

      [download]

      and rerun perl -Ilib Makefile.PL, I get the correct full Makefile. Removing that BEIGN statement make the Makefile 0 bytes again.

      If I comment out the line:

      # sub dl_load_flags { DL_GLOBAL }

      I still get an empty Makefile. There be demons in there.

[reply]
[d/l]
[select]

      He he. I can't wait to see what the hell the answer to all of this mess is. If I put this in my Makefile.PL 

      print 'foo';

      [download]

      My Makefile gets created. So, it seems to point to an APR/XS I/O buffering issue outside of MP.

[reply]
[d/l]
        Does something equally perplexing solve the problems with the sqlite tests?
[reply]

In Section Seekers of Perl Wisdom