Thread: pgsql: Allow building with MSVC and Strawberry perl
Allow building with MSVC and Strawberry perl Strawberry uses __builtin_expect which Visual C doesn't have. For this case define it as a noop. Solution taken from vim sources. Backpatch to all live branches Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/341f4e002d461a3c5513cb864490cddae2b43a64 Modified Files -------------- src/pl/plperl/plperl.h | 2 ++ 1 file changed, 2 insertions(+)
On 2022-11-25 Fr 15:38, Andrew Dunstan wrote: > Allow building with MSVC and Strawberry perl > > Strawberry uses __builtin_expect which Visual C doesn't have. For this > case define it as a noop. Solution taken from vim sources. Argh! drongo doesn't seem to like this. I thought I'd tested it. A little further googling suggests that instead of #define __builtin_expect(expr, val) (expr) we should probably have something like #define __builtin_expect(expr, val) ((expr) == (val)) I'll try that. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Hi, On 2022-11-25 17:11:51 -0500, Andrew Dunstan wrote: > On 2022-11-25 Fr 15:38, Andrew Dunstan wrote: > > Allow building with MSVC and Strawberry perl > > > > Strawberry uses __builtin_expect which Visual C doesn't have. For this > > case define it as a noop. Solution taken from vim sources. FWIW, to get a newer strawberry perl to work with msvc we need more than this. At the very least -DNO_THREAD_SAFE_LOCALE, see https://postgr.es/m/20220130221659.tlyr2lbw3wk22owg%40alap3.anarazel.de > > Argh! drongo doesn't seem to like this. I thought I'd tested it. > > A little further googling suggests that instead of > > > #define __builtin_expect(expr, val) (expr) > > > we should probably have something like > > > #define __builtin_expect(expr, val) ((expr) == (val)) That doesn't seem right - val isn't something to compare to, it's the expected return value. This afaict would compute bogus value in a number of scenarios. Note that perl's own definition is: #ifdef HAS_BUILTIN_EXPECT # define EXPECT(expr,val) __builtin_expect(expr,val) #else # define EXPECT(expr,val) (expr) #endif So we really should be able to get away with #define __builtin_expect(expr, val) (expr) I don't see why drongo's problems would go away with #define __builtin_expect(expr, val) ((expr) == (val)) anyway? FWIW a meson build with msvc 2019 and strawberry perl 5.32 builds fine with #define __builtin_expect(expr, val) (expr) Greetings, Andres Freund
Hi, On 2022-11-25 15:33:31 -0800, Andres Freund wrote: > FWIW a meson build with msvc 2019 and strawberry perl 5.32 builds fine with > #define __builtin_expect(expr, val) (expr) And it does so with src/tools/msvc as well. I think we might need a preprocessed plperl.c from drongo to analyze this further. There might be some unrelated under-specified build issues, I get weird errors if I start by building plperl.vcxproj, without first having built postgres.vcxproj. But ... Greetings, Andres Freund
On 2022-11-25 Fr 18:48, Andres Freund wrote: > Hi, > > On 2022-11-25 15:33:31 -0800, Andres Freund wrote: >> FWIW a meson build with msvc 2019 and strawberry perl 5.32 builds fine with >> #define __builtin_expect(expr, val) (expr) > And it does so with src/tools/msvc as well. I think we might need a > preprocessed plperl.c from drongo to analyze this further. > > There might be some unrelated under-specified build issues, I get weird errors > if I start by building plperl.vcxproj, without first having built > postgres.vcxproj. But ... > Yeah, drongo builds fine too. It's the handshake thing that's the current issue. I'll see if forcing -DNO_THREAD_SAFE_LOCALE works. Thanks cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Hi, On 2022-11-25 18:56:02 -0500, Andrew Dunstan wrote: > On 2022-11-25 Fr 18:48, Andres Freund wrote: > > On 2022-11-25 15:33:31 -0800, Andres Freund wrote: > >> FWIW a meson build with msvc 2019 and strawberry perl 5.32 builds fine with > >> #define __builtin_expect(expr, val) (expr) > > And it does so with src/tools/msvc as well. I think we might need a > > preprocessed plperl.c from drongo to analyze this further. > > > > There might be some unrelated under-specified build issues, I get weird errors > > if I start by building plperl.vcxproj, without first having built > > postgres.vcxproj. But ... > > > > > Yeah, drongo builds fine too. Oh - I just looked at HEAD, where it fails in the 'make' stage on the BF. But I now see the PLCheck-C failures in the older branches. > It's the handshake thing that's the current issue. I'll see if forcing > -DNO_THREAD_SAFE_LOCALE works. With it tests do pass for me with meson + msvc + perl 5.32. Greetings, Andres Freund