Jump to content

scotth

Members
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

0 Neutral

About scotth

  • Rank
    Newbie
  1. Thanks for your response. Do you have an idea of what risks would be involved if Plastic were to access the wrong zlib.dll? I can try to be careful to directly open it from the install path, but someone else in the future may not kown to do that.
  2. I am dealing with dll conflicts between perl and the plastic scm client. zlib.dll, in particular causes me issues. Another developer that is no longer here setup our server, so I am slightly fearful of changing the path order in the environment variables. The plastic client is the first path listed currently. Our documentation for a perl process that uses zlib.dll calls for us to rename the plastic copy of the dll before running the process. I'm getting by in doing that, but it's a bit clunky. Has anyone had good luck in getting plastic and perl to play well together? Here's some of the info from an application error: Faulting application name: perl.exe, version: 5.8.6.811, time stamp: 0x41c9e730 Faulting module name: zlib.dll, version: 1.2.3.0, time stamp: 0x42de1dda Exception code: 0xc0000005 Fault offset: 0x00004520 Faulting process id: 0x1654 Faulting application start time: 0x01d5ee7a2029b786 Faulting application path: d:\perl\bin\perl.exe Faulting module path: D:\Program Files\PlasticSCM4\client\zlib.dll
×
×
  • Create New...