| 1 | | Sadly still a problem. What's annoying is I can't replicate it on my desktop. So it's not even a simple matter of pg10 32-bit windows since using the same compiled cluster I can't replicate it. On winnie it only happens on her pg10 32-bit runs. thought that may be because the others are tested under Vc++ and this one is pure ming. Though even on my machine where I have a pure mingw64-w32 test it doesn't fail. Can't imagine its something as stupid as because she's running windows 2012 and I'm running windows 7. |
| | 1 | Sadly still a problem. What's annoying is I can't replicate it on my desktop. So it's not even a simple matter of pg10 32-bit windows since using the same compiled cluster I can't replicate it. On winnie it only happens on her pg10 32-bit runs. thought that may be because the others are tested under Vc++ and this one is pure ming since EDB hasn't shipped their pg10 VC++ I can test against. |
| | 2 | |
| | 3 | Though even on my machine where I have a pure mingw64-w32 test it doesn't fail. Can't imagine its something as stupid as because she's running windows 2012 and I'm running windows 7. hmm or maybe it is something in the mvcrt implementations. Because mingw64-w32 would use what is native to the OS and I think the windows 7 / windows 2012 mvcrt might be a little different. |
| | 4 | |
| | 5 | I probably don't see it with the vc++ builds because the mvcrt for vc++ is different and pegged to compiled version of vc++ rather than the OS. I'm going to test 9.6w32mingw on winnie to prove out that theory. If so might just be a bug in the msvcrt 32-bit that ships with windows 2012r2 64-bit winnie's running. I'm not so concerned about it because in the field only EDB ships the windows 32-bit versions and since they compile with VC++ somethig or other, they aren't relying on the msvcrt that ships with the OS. |
