Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Tuesday November 14, 2006
08:50 PM

More test reports for Crypt::Rijndael, please

[ #31608 ]

I've been getting a fair number of emails about Crypt::Rijndael, so I guess a lot of people must be using it. I thought it was some little used thing that nobody cared about. :)

I think I've fixed most of the bugs in RT, but I want to wait for more CPAN Tester reports to ensure the systems that had problems previously now have them fixed. I would certainly appreciate any CPAN testers who can add these data points for Crypt::Rijndael:

Systems that had failures in 0.05 but not passes in 0.06_02 yet:

  • Linux 2.4.7-0.44.31 (s390x-linux)
  • MSWin32 4.0 (MSWin32-x86-multi-thread)
  • Solaris 2.9 (sun4-solaris)
  • Aix 5.3.0.0 (aix-thread-multi-64int)
  • Darwin 8.0 (darwin-thread-multi-2level)
  • Freebsd 6.0-release (alpha-freebsd)

Systems with bugs in RT:

  • Debian 3.0 on alpha (guessing 64 bit)
  • Compaq Tru64 5.0 on alpha
  • Solaris 8 x86
  • Solaris 8 SPARC
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • On Strawberry Perl, make fails with the above error from rinjdael.h (line 34). Conflicts with MINGW basetsd.h (line 56).
    • I found the libjpeg and X86Free had similar woes because someone else was defining these types globally. I think MinGW does this in basetsd.h, but in the CVS repository it's in the Attic, so I'm not sure what's going on there. CVS comments are to explain why you did something, people!

      I've uploaded 0.06_03, which first checks for previous definitions before trying to do the typedef. I have to assume, however, that the previous definitions are right unless I want to undef them. For the moment, I'll trust the
      • 0.06_03 still wouldn't build for me. I did some quick hacking to rijndael.h to work around the definitions in a different way and got it to build:

        /* If sys/types doesn't work, *and* something else hasn't defined these,
        * lets do it ourselves.
        *
        * MinGW defines these in win32api/include/basetsd.h, so avoid a conflict
        */

        #ifdef __MINGW_H
        typedef unsigned int UINT32;
        #else
        typedef unsigned long UINT32;
        #endif

        typedef unsigned char UINT8;

        I have no idea if this works elsewhere or screws anything else up, but "w

        • Well, drats. What the heck is MinGW doing? If I don't do anything when it's already defined it fails too. Odd. Maybe I'm doing something wrong.

          I've tried the _MINGW_H trick in 0.06_04, but that seems like the wrong solution, even if it works. That's probably just me, though. I haven't found any programmer's guide to what we should do for this, and the most I found in the Perl sources was in POSIX.xs.
  • See topic. Strawberry/win32 fails for me quite the same as for xdg.

    Cheers,
    Steffen
  • On ActiveState Perl, rijndael.h fails on line 30 as follows: " error: conflicting types for 'UINT32'". I used CPANPPlus to attempt installation as this module doesn't show up in AS's list of available modules in their PPM.
  • Hi,

    I am the owner of this box.

    Unfortunately, it isn't powered up all the time so your upload has probably slipped through the net ( I use RECENT to generate a list to test when the box does get powered up ).

    I shall try and remember to add your module to my list when I next power up.

    Cheers.
  • Builds, tests and installs fine on OS X 10.4.8, on both PPC and Intel
  • Despite the #ifdef for MINGW, 0.06_09 still fails on strawberry perl.

    After replacing "long" with "int" in the MINGW case (similar to dagolden's patch above), it compiles and tests okay.

    Steffen
    • Does it compile and test okay with the other Windows perls though? It's really not enough to say it compiles on a particular architecture. That's one of the problems with patching C :)
      • Works on AS Perl with MinGW. I cannot test with VC++ which I don't have.
        • Note that I meant to say that the *patched* version works fine with MinGW+AS Perl. The unpatched 0.06_09 does *not* compile!

          Sorry I didn't say this explicitly right away.

          Cheers,
          Steffen