Reading the linked thread, I didn't see a clear cause clearly called out, but it looked to me like the problem in that case was that the DLL's base address conflicted with some other DLL's base address.

base address conflicts only happen on cygwin due to how they implement their fork. Cygwin might have been fixed by now. Very old Win32 GCC (2.x/3.x) also couldn't generate relocation information, or created garbage entries, and the garbage entries only were a problem if the Win32 DLL loader tried to relocate.

One next step I might do is watch what the perl process is doing when this fails. Is there a sysinternals-like process monitor that works on Windows 7 these days? Even a file system monitor might help in pointing at which library is the real problem. I'm not sure how to do the equivalent on Windows, but that shouldn't be hard to look up.

Dependency Walker is what you want. Use the profiling feature in DW. Procmon will also work, but its output is extremely noisy when all you want DLL info, not every file, thread life, and reg access. Manipulating the filters in procmon is alot of work when you could just use dep walker instead.

On Unix, I'd ask lsof to tell me what other DLLs are loaded so I could just check for conflicting base addresses (seems a poor system to be vulnerable to such -- but maybe I misunderstood the real root cause in that other thread).

Doesn't Unix always make PIC ELFs that dont need relocation? and ELF has relocation if you really want it anyway in the standard.