New Windows animal, mostly ecpg trouble (was: Crash with old Windows on new CPU)
| От | Christian Ullrich |
|---|---|
| Тема | New Windows animal, mostly ecpg trouble (was: Crash with old Windows on new CPU) |
| Дата | |
| Msg-id | 56E197F5.6000704@chrullrich.net обсуждение исходный текст |
| Ответ на | Re: Crash with old Windows on new CPU (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Список | pgsql-hackers |
* Alvaro Herrera wrote: > Magnus Hagander wrote: >> On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich <chris@chrullrich.net> >> wrote: >>> And apparently not a single one with VS 2013. OK, I'll see what I can do >>> about setting some up soonish, at least with (server) 2008 and (client) 7. >>> FWIW, I have a local build of 9.5.1 with this patch in daily use on 2008 >>> now, with no complaints. >> >> Having that added to the buildfarm would definitely be very useful! > > Yeah, ideally we would have one buildfarm member for each MSVC compiler > supported by each Windows version. AFAICS we only have > > Windows 8 8.1 Pro Visual Studio 2012 x86_64 > Windows Server 2008 R2 (64bit) Visual C++ 2005 AMD64 > Windows Server 2003 R2 5.2.3790 MSVC 2005 Express 8.0.50727.42 x86 > Vista Ultimate 6.0.6000 MSVC 2005 Pro 8.0.50727.867 x86 > Windows XP-PRO SP3 MSVC++ 2008 Express i686 Add to that Windows 7 with Visual Studio 2013 (x64), named woodlouse, and there will be another one sometime over the weekend. Setting up Windows animals is a major pain; no wonder so few people run any. I spent some hours getting rid of random linker errors in ecpg (kernel32.lib not found, msvcrt.lib not found, or unresolved symbols that should be in one of the two); they finally went away when I stopped defining the build environment in build-farm.conf and ran vcvarsall.bat instead (this was probably pilot error; I think I had a mix of x86 and x64 paths there). At that point, I managed one successful run on HEAD. Things started failing in ecpg again after that, with crashes of the test programs for the thread-thread and thread-prep test cases, apparently somewhere in setlocale(). I had to --skip-steps=ecpg-check because the crashes cause blocking UI. The other troublemaker is plperl; it produces a wall of compiler errors which I cleverly did not copy, most are about something not being in a formal parameter list. Some preprocessor trouble, I suspect. This is with both ActiveState and Strawberry Perl. I did not try Tcl, and plpython3 apparently builds, but I cannot see any tests being run. -- Christian
В списке pgsql-hackers по дате отправления: