On 17 February 2015 at 13:27, Michael Lackhoff <mich...@lackhoff.de> wrote: > Am 17.02.2015 um 14:14 schrieb Steve Hay: > >> You can't. The VC9 build of the mod_perl components are not compatible >> with StrawberryPerl, which is built with gcc and therefore uses a >> different CRT (msvcrt.dll vs msvcr90.dll). >> >> The 32-bit components that I've built before were built with VC6 in >> order to use the same CRT as StrawberryPerl/ActivePerl, but that's no >> longer an option since ActiveState only make 64-bit-int versions of >> their 32-bit ActivePerl available now and the 64-bit-int build option >> doesn't work with VC6 due to bugs in that ancient compiler. I can make >> a 32-bit-int VC6 perl myself, of course, but then the mod_perl >> components still won't match ActivePerl because of the 32/64-bit-int >> mismatch... That is why I've only made 64-bit versions available >> recently... >> >> And that's why I need to change mod_perl so that it can be built with >> gcc/dmake. >> >> (I asked ActiveState to consider making 32-bit-int versions available >> as well (like StrawberryPerl do), but they declined.) > > > But then it should be possible to build a 32-bit version with VC6 for > Strawberry, just not for Activestate? Or did I misunderstand your last > sentence? > Since I use Strawberry that would be fine with me. I think I even still have > VC6 around somewhere...
Yes, that should be possible, albeit using a compatible custom-built VC6 perl since StrawberryPerl itself is a gcc/dmake system. It will only work for the 32-bit-int StrawberryPerl, though: with the 64-bit-int version you'll have the same problem as with ActivePerl. > > Or else -- given the uncertainty of predictions -- do you have an estimation > when you get into the gcc/dmake thing? > I will have a look this weekend if I have time.