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:
Re:Strawberry Perl: conflicting types for UINT32
brian_d_foy on 2006-11-15T17:13:51
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 previous definitions.Re:Strawberry Perl: conflicting types for UINT32
dagolden on 2006-11-15T19:15:38
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 "works for me" on Strawberry Perl Alpha 2
Re:Strawberry Perl: conflicting types for UINT32
brian_d_foy on 2006-11-15T20:47:27
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.
Re:Freebsd 6.0-release (alpha-freebsd)
BinGOs on 2006-11-18T13:58:29
All the modules were in RECENT, processed on alpha-freebsd today:
All PASSes
Re:0.06_09 still fails on strawberry
brian_d_foy on 2006-12-18T21:27:21
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:) Re:0.06_09 still fails on strawberry
tsee on 2006-12-18T22:26:46
Works on AS Perl with MinGW. I cannot test with VC++ which I don't have.Re:0.06_09 still fails on strawberry
tsee on 2006-12-18T23:12:40
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
