Re: Darwin: make check fails with "child process exited with exit code 134"
От | Tom Lane |
---|---|
Тема | Re: Darwin: make check fails with "child process exited with exit code 134" |
Дата | |
Msg-id | 9220.1382988316@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Darwin: make check fails with "child process exited with exit code 134" (Matthias Schmitt <freak002@mmp.lu>) |
Ответы |
Re: Darwin: make check fails with "child process exited with exit
code 134"
|
Список | pgsql-bugs |
Matthias Schmitt <freak002@mmp.lu> writes: > configure: using compiler=i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) I realized that almost certainly, this compiler is leftover from a Lion-era installation of Xcode. The build number is a little bit ahead of the rather old Xcode on my own Lion machine, but the reference to darwin11 seems rather conclusive. So what is probably going on here is that the occurrence of the assert trap is dependent on using this older compiler (and probably, older system #include files along with it) along with the Mavericks version of libc.dylib. I'm not sure exactly what the mechanism for that is, but I see some differences in the predefined macros on my Lion box and on my Mavericks box (notably __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) so I'm guessing there's something about that that disables the trap. If this is correct, then we can't really rely on the Apple build to flag overlap violations, because it'll only happen on arguably-misconfigured installations. So I'm thinking that Andres' idea of a buildfarm member running with valgrind might be the most practical way to catch these. regards, tom lane
В списке pgsql-bugs по дате отправления: