Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11
От | Mark Dilger |
---|---|
Тема | Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11 |
Дата | |
Msg-id | 1427184E-E4BD-4AE3-A7DD-EBB61B37EA44@gmail.com обсуждение исходный текст |
Ответ на | Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Windows build broken starting atda9b580d89903fee871cf54845ffa2b26bda2e11
|
Список | pgsql-hackers |
> On May 15, 2018, at 8:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnorter@gmail.com> writes: >> My best guess at the moment is: > >> diff --git a/src/backend/utils/init/globals.c b/src/backend/utils/init/globals.c >> index c1f0441b08..0a3163398f 100644 >> --- a/src/backend/utils/init/globals.c >> +++ b/src/backend/utils/init/globals.c >> @@ -16,8 +16,11 @@ >> * >> *------------------------------------------------------------------------- >> */ >> +#include <sys/stat.h> >> + >> #include "postgres.h" > >> +#include "common/file_perm.h" > > Yipes. Frost, you didn't really do that did you? That's a blatant > break of the "c.h must come first" rule. Whether or not it broke the > Windows build, there are other platforms it'll break. > >> Indeed, the following change (shown here for illustrative purposes only; please >> don't commit it this way) fixes the problem, at least in my build environment: > > That's pretty ugly, but what happens if you just move the <sys/stat.h> > inclusion to immediately after postgres.h, as is our normal custom? That also works. mark
В списке pgsql-hackers по дате отправления: