[RFC] building postgres with meson

Hi,

On 2021-10-12 01:37:21 -0700, Andres Freund wrote:

non-cached build (world-bin):
current: 40.46s
ninja: 7.31s

Interestingly this is pretty close to the minimum achievable on my
machine from the buildsystem perspective.

A build with -fuse-ld=lld, which the above didn't use, takes 6.979s. The
critical path is

bison gram.y -> gram.c 4.13s
gcc gram.c -> gram.o 2.05s
gcc postgres .... 0.317

A very helpful visualization is to transform ninja's build logs into a
tracefile with https://github.com/nico/ninjatracing

I attached an example - the trace.json.gz can be uploaded as-is to
https://ui.perfetto.dev/

It's quite a bit of of fun to look at imo.

There's a few other things quickly apparent:

- genbki prevents build progress due to dependencies on the generated
headers.
- the absolutely stupid way I implemented the python2->python3
regression test output conversion uses up a fair bit of resources
- tablecmds.c, pg_dump.c, xlog.c and a few other files are starting to
big enough to be problematic compile-time wise

Greetings,

Andres Freund

On 12.10.21 10:37, Andres Freund wrote:

For the last year or so I've on and off tinkered with $subject. I think
it's in a state worth sharing now. First, let's look at a little
comparison.

I played with $subject a few years ago and liked it. I think, like you
said, meson is the best way forward. I support this project.

One problem I noticed back then was that some choices that we currently
determine ourselves in configure or the makefiles are hardcoded in
meson. For example, at the time, gcc on macOS was not supported. Meson
thought, if you are on macOS, you are surely using the Apple compiler,
and it supports these options. Fixing that required patches deep in the
bowels of the meson source code (and, in practice, waiting for a new
release etc.). I strongly suspect this isn't the only such problem.
For example, the shared library build behavior has been carefully tuned
in opinionated ways. With the autotools chain, one can override
anything with enough violence; so we have always felt free to do that.
I haven't followed it in a while, so I don't know what the situation is
now; but it is a concern, because we have always felt free to try new
and unusual build tools (Sun compiler, Intel compiler,
clang-when-it-was-new) early without waiting for anyone else.

On Tue, Oct 12, 2021 at 9:31 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:

One problem I noticed back then was that some choices that we currently
determine ourselves in configure or the makefiles are hardcoded in
meson. For example, at the time, gcc on macOS was not supported. Meson
thought, if you are on macOS, you are surely using the Apple compiler,
and it supports these options. Fixing that required patches deep in the
bowels of the meson source code (and, in practice, waiting for a new
release etc.). I strongly suspect this isn't the only such problem.
For example, the shared library build behavior has been carefully tuned
in opinionated ways. With the autotools chain, one can override
anything with enough violence; so we have always felt free to do that.
I haven't followed it in a while, so I don't know what the situation is
now; but it is a concern, because we have always felt free to try new
and unusual build tools (Sun compiler, Intel compiler,
clang-when-it-was-new) early without waiting for anyone else.

I think we're going to need some solution to this problem. We have too
many people here with strong opinions about questions like this for me
to feel good about the idea that we're going to collectively be OK
with leaving these sorts of decisions up to some other project.

From my point of view, the time it takes to run configure is annoying,
but the build time is pretty fine. On my system, configure takes about
33 seconds, and a full rebuild with 'make -j8' takes 14.5 seconds (I
am using ccache). Moreover, most of the time when I run make, I'm only
doing a partial rebuild, so it's near-instantaneous.

--
Robert Haas
EDB: http://www.enterprisedb.com

On 10/12/21 4:37 AM, Andres Freund wrote:

git remote add andres git@github.com:anarazel/postgres.git

ITYM:

git remote add andres git://github.com/anarazel/postgres.git

cheers

andrew
�
--
Andrew Dunstan
EDB: https://www.enterprisedb.com

.

út 12. 10. 2021 v 10:37 odesílatel Andres Freund <andres@anarazel.de> napsal:

Hi,

For the last year or so I've on and off tinkered with $subject. I think
it's in a state worth sharing now. First, let's look at a little
comparison.

My workstation:

non-cached configure:
current: 11.80s
meson: 6.67s

non-cached build (world-bin):
current: 40.46s
ninja: 7.31s

no-change build:
current: 1.17s
ninja: 0.06s

test world:
current: 105s
meson: 63s

What actually started to motivate me however were the long times windows
builds took to come back with testsresults. On CI, with the same machine
config:

build:
current: 202s (doesn't include genbki etc)
meson+ninja: 140s
meson+msbuild: 206s

test:
current: 1323s (many commands)
meson: 903s (single command)

(note that the test comparison isn't quite fair - there's a few tests
missing, but it's just small contrib ones afaik)

The biggest difference to me however is not the speed, but how readable
the output is.

Running the tests with meson in a terminal, shows the number of tests
that completed out of how many total, how much time has passed, how long
the currently running tests already have been running.

At the end of a testrun a count of tests is shown:

188/189 postgresql:tap+pg_basebackup / pg_basebackup/t/010_pg_basebackup.pl OK 39.51s 110 subtests passed
189/189 postgresql:isolation+snapshot_too_old / snapshot_too_old/isolation OK 62.93s

Ok: 188
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0

Full log written to /tmp/meson/meson-logs/testlog.txt

The log has the output of the tests and ends with:

Summary of Failures:
120/189 postgresql:tap+recovery / recovery/t/007_sync_rep.pl ERROR 7.16s (exit status 255 or signal 127 SIGinvalid)

Quite the difference to make check-world -jnn output.

So, now that the teasing is done, let me explain a bit what lead me down
this path:

Autoconf + make is not being actively developed. Especially autoconf is
*barely* in maintenance mode - despite many shortcomings and bugs. It's
also technology that very few want to use - autoconf m4 is scary, and
it's scarier for people that started more recently than a lot of us
committers for example.

Recursive make as we use it is hard to get right. One reason the clean
make build is so slow compared to meson is that we had to resort to
.NOTPARALLEL to handle dependencies in a bunch of places. And despite
that, I quite regularly see incremental build failures that can be
resolved by retrying the build.

While we have incremental build via --enable-depend, they don't work
that reliable (i.e. misses necessary rebuilds) and yet is often too
aggressive. More modern build system can keep track of the precise
command used to build a target and rebuild it when that command changes.

We also don't just have the autoconf / make buildsystem, there's also
the msvc project generator - something most of us unix-y folks do not
like to touch. I think that, combined with there being no easy way to
run all tests, and it being just different, really hurt our windows
developer appeal (and subsequently the quality of postgres on
windows). I'm not saying this to ding the project generator - that was
well before there were decent "meta" buildsystems out there (and in some
ways it is a small one itself).

The last big issue I have with the current situation is that there's no
good test integration. make check-world output is essentially unreadable
/ not automatically parseable. Which led to the buildfarm having a
separate list of things it needs to test, so that failures can be
pinpointed and paired with appropriate logs. That approach unfortunately
doesn't scale well to multi-core CPUs, slowing down the buildfarm by a
fair bit.

This all led to me to experiment with improvements. I tried a few
somewhat crazy but incremental things like converting our buildsystem to
non-recursive make (I got it to build the backend, but it's too hard to
do manually I think), or to not run tests during the recursive make
check-world, but to append commands to a list of tests, that then is run
by a helper (can kinda be made to work). In the end I concluded that
the amount of time we'd need to invest to maintain our more-and-more
custom buildsystem going forward doesn't make sense.

Which lead me to look around and analyze which other buildsystems there
are that could make some sense for us. The halfway decent list includes,
I think:
1) cmake
2) bazel
3) meson

cmake would be a decent choice, I think. However, I just can't fully
warm up to it. Something about it just doesn't quite sit right with
me. That's not a good enough reason to prevent others from suggesting to
use it, but it's good enough to justify not investing a lot of time in
it myself.

Bazel has some nice architectural properties. But it requires a JVM to
run - I think that basically makes it insuitable for us. And the build
information seems quite arduous to maintain too.

Which left me with meson. It is a meta-buildsystem that can do the
actual work of building via ninja (the most common one, also targeted by
cmake), msbuild (visual studio project files, important for GUI work)
and xcode projects (I assume that's for a macos IDE, but I haven't tried
to use it). Meson roughly does what autoconf+automake did, in a
python-esque DSL, and outputs build-instructions for ninja / msbuild /
xcode. One interesting bit is that meson itself is written in python (
and fairly easy to contribute too - I got a few changes in now).

I don't think meson is perfect architecturally - e.g. its insistence on
not having functions ends up making it a bit harder to not end up
duplicating code. There's some user-interface oddities that are now hard
to fix fully, due to the faily wide usage. But all-in-all it's pretty
nice to use.

Its worth calling out that a lot of large open source projects have been
/ are migrating to meson. qemu/kvm, mesa (core part of graphics stack on
linux and also widely used in other platforms), a good chunk of GNOME,
and quite a few more. Due to that it seems unlikely to be abandoned
soon.

As far as I can tell the only OS that postgres currently supports that
meson doesn't support is HPUX. It'd likely be fairly easy to add
gcc-on-hpux support, a chunk more to add support for the proprietary
ones.

The attached patch (meson support is 0016, the rest is prerequisites
that aren't that interesting at this stage) converts most of postgres to
meson. There's a few missing contrib modules, only about half the
optional library dependencies are implemented, and I've only built on
x64. It builds on freebsd, linux, macos and windows (both ninja and
msbuild) and cross builds from linux to windows. Thomas helped make the
freebsd / macos pieces a reality, thanks!

I took a number of shortcuts (although there used to be a *lot*
more). So this shouldn't be reviewed to the normal standard of the
community - it's a prototype. But I think it's in a complete enough
shape that it allows to do a well-informed evaluation.

What doesn't yet work/ build:

- plenty optional libraries, contrib, NLS, docs build

- PGXS - and I don't yet know what to best do about it. One
backward-compatible way would be to continue use makefiles for pgxs,
but do the necessary replacement of Makefile.global.in via meson (and
not use that for postgres' own build). But that doesn't really
provide a nicer path for building postgres extensions on windows, so
it'd definitely not be a long-term path.

- JIT bitcode generation for anything but src/backend.

- anything but modern-ish x86. That's proably a small amount of work,
but something that needs to be done.

- exporting all symbols for extension modules on windows (the stuff for
postgres is implemented). Instead I marked the relevant symbols als
declspec(dllexport). I think we should do that regardless of the
buildsystem change. Restricting symbol visibility via gcc's
-fvisibility=hidden for extensions results in a substantially reduced
number of exported symbols, and even reduces object size (and I think
improves the code too). I'll send an email about that separately.

There's a lot more stuff to talk about, but I'll stop with a small bit
of instructions below:

Demo / instructions:
# Get code
git remote add andres git@github.com:anarazel/postgres.git
git fetch andres
git checkout --track andres/meson

# setup build directory
meson setup build --buildtype debug
cd build

# build (uses automatically as many cores as available)
ninja

I'm getting errors at this step. You can find my output at
https://pastebin.com/Ar5VqfFG. Setup went well without errors. Is that
expected for now?

On 10/12/21 4:37 AM, Andres Freund wrote:

# setup build directory
meson setup build --buildtype debug

I took this for an outing on msys2 and it just seems to hang. If it's not hanging it's unbelievably slow.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:

I think we're going to need some solution to this problem. We have too
many people here with strong opinions about questions like this for me
to feel good about the idea that we're going to collectively be OK
with leaving these sorts of decisions up to some other project.

Agreed. I'm willing to put up with the costs of moving to some
other build system, but not if it dictates choices we don't want to
make about the end products.

From my point of view, the time it takes to run configure is annoying,
but the build time is pretty fine. On my system, configure takes about
33 seconds, and a full rebuild with 'make -j8' takes 14.5 seconds (I
am using ccache). Moreover, most of the time when I run make, I'm only
doing a partial rebuild, so it's near-instantaneous.

Read about Autoconf's --cache-file option. That and ccache are
absolutely essential tools IMO.

regards, tom lane

On 10/12/21 11:28 AM, Andrew Dunstan wrote:

On 10/12/21 4:37 AM, Andres Freund wrote:

# setup build directory
meson setup build --buildtype debug

I took this for an outing on msys2 and it just seems to hang. If it's not hanging it's unbelievably slow.

It hung because it expected the compiler to be 'ccache cc'. Hanging in
such a case is kinda unforgivable. I remedied that by setting 'CC=gcc'
but it then errored out looking for perl libs. I think msys2 is going to
be a bit difficult here :-(

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Hi,

On 2021-10-12 15:30:57 +0200, Peter Eisentraut wrote:

I played with $subject a few years ago and liked it. I think, like you
said, meson is the best way forward. I support this project.

Cool.

One problem I noticed back then was that some choices that we currently
determine ourselves in configure or the makefiles are hardcoded in meson.

Yea, there's some of that. I think some degree of reduction in flexibility is
needed to realistically target multiple "backend" build-system like visual
studio project files etc. but I wish there were a bit less of that
nonetheless.

For example, at the time, gcc on macOS was not supported. Meson thought, if
you are on macOS, you are surely using the Apple compiler, and it supports
these options.

I'm pretty sure this one now can just be overridden with CC=gcc. It can on
linux and windows, but I don't have ready interactive access with a mac
(leaving cirrus asside, which now has a "start a terminal" option...).

For example, the shared library build behavior has been carefully tuned in
opinionated ways. With the autotools chain, one can override anything with
enough violence; so we have always felt free to do that. I haven't followed
it in a while, so I don't know what the situation is now; but it is a
concern, because we have always felt free to try new and unusual build tools
(Sun compiler, Intel compiler, clang-when-it-was-new) early without waiting
for anyone else.

It's possible to just take over building e.g. shared libraries ourselves with
custom targets. Although it'd be a bit annoying to do. The bigger problem is
that that e.g. wouldn't play that nicely with generating visual studio
projects, which require to generate link steps in a certain way. It'd build,
but the GUI might loose some of its options. Etc.

Greetings,

Andres Freund

Hi,

On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:

It hung because it expected the compiler to be 'ccache cc'. Hanging in
such a case is kinda unforgivable. I remedied that by setting 'CC=gcc'
but it then errored out looking for perl libs. I think msys2 is going to
be a bit difficult here :-(

Hm. Yea, the perl thing is my fault - you should be able to get past it with
-Dperl=disabled, and I'll take a look at fixing the perl detection. (*)

I can't reproduce the hanging though. I needed to install bison, flex and
ninja and disable perl as described above, but then it built just fine.

It does seems to crash somewhere in the main regression tests though, I think
I don't do the "set stack depth" dance correctly for msys.

If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?

(*) I've for now made most dependencies autodetected, unless you pass
--auto-features disabled to collectively disable all the auto-detected
features. Initially I had mirrored the autoconf behaviour, but I got sick of
forgetting to turn off readline or zlib on windows. And then it was useful to
test on multiple operating systems...

For working on windows meson's wraps are quite useful. I've not added that to
the git branch, but if you manually do
mkdir subprojects
meson wrap install lz4
meson wrap install zlib
building with -Dzlib=enabled -Dlz4=enabled will fall back to building lz4,
zlib as-needed.

I was wondering about adding a binary wrap for e.g. bison, flex on windows, so
that the process of getting a build going isn't as arduous.

Greetings,

Andres Freund

Hi,

On 2021-10-12 17:21:50 +0200, Josef Šimánek wrote:

# build (uses automatically as many cores as available)
ninja

I'm getting errors at this step. You can find my output at
https://pastebin.com/Ar5VqfFG. Setup went well without errors. Is that
expected for now?

Thanks, that's helpful. And no, that's not expected (*), it should be fixed.

What OS / distribution / version is this?

Can you build postgres "normally" with --with-gss? Seems like we're ending up
with a version of gssapi that we're not compatible with.

You should be able to get past this by disabling gss using meson configure
-Dgssapi=disabled.

Greetings,

Andres Freund

* except kinda, in the sense that I'd expect it to be buggy, given that I've
run it only on a few machines and it's very, uh, bleeding edge

Hi,

On 2021-10-12 09:59:26 -0700, Andres Freund wrote:

On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:

It hung because it expected the compiler to be 'ccache cc'. Hanging in
such a case is kinda unforgivable. I remedied that by setting 'CC=gcc'
but it then errored out looking for perl libs. I think msys2 is going to
be a bit difficult here :-(

Hm. Yea, the perl thing is my fault - you should be able to get past it with
-Dperl=disabled, and I'll take a look at fixing the perl detection. (*)

This is a weird one. I don't know much about msys, so it's probably related to
that. Perl spits out /usr/lib/perl5/core_perl/ as its archlibexp. According to
shell commands that exists, but not according to msys's own python

$ /mingw64/bin/python -c "import os; p = '/usr/lib/perl5/core_perl/CORE'; print(f'does {p} exist:', os.path.exists(p))"
does /usr/lib/perl5/core_perl/CORE exist: False

$ ls -ld /usr/lib/perl5/core_perl/CORE
drwxr-xr-x 1 anfreund anfreund 0 Oct 10 10:19 /usr/lib/perl5/core_perl/CORE

So it's not too surprising that that doesn't work out. It's easy enough to
work around, but still pretty weird.

I pushed a workaround for the config-time error, but it doesn't yet recognize
msys perl correctly. But at least it's not alone in that - configure doesn't
seem to either, so I'm probably doing something wrong :)

I can't reproduce the hanging though. I needed to install bison, flex and
ninja and disable perl as described above, but then it built just fine.

It does seems to crash somewhere in the main regression tests though, I think
I don't do the "set stack depth" dance correctly for msys.

That was it - just hadn't ported setting -Wl,--stack=... for !msvc
windows. Pushed the fix for that out.

I guess I should figure out how to commandline install msys and add it to CI.

Greetings,

Andres Freund

On 10/12/21 12:59 PM, Andres Freund wrote:

If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?

Here's the entire thing

# cat 
C:/tools/msys64/home/Administrator/postgresql/build/meson-logs/meson-log.txt
Build started at 2021-10-12T18:08:34.387568
Main binary: C:/tools/msys64/mingw64/bin/python.exe
Build Options: -Dbuildtype=debug
Python system: Windows
The Meson build system
Version: 0.59.1
Source dir: C:/tools/msys64/home/Administrator/postgresql
Build dir: C:/tools/msys64/home/Administrator/postgresql/build
Build type: native build
Project name: postgresql
Project version: 15devel
Sanity testing C compiler: ccache cc
Is cross compiler: False.
Sanity check compiler command line: ccache cc sanitycheckc.c -o
sanitycheckc.exe -D_FILE_OFFSET_BITS=64
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----

meson.build:1:0: ERROR: Compiler ccache cc can not compile programs.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Hi,

On 2021-10-12 14:11:39 -0400, Andrew Dunstan wrote:

On 10/12/21 12:59 PM, Andres Freund wrote:

If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?

Here's the entire thing

Sanity check compiler command line: ccache cc sanitycheckc.c -o
sanitycheckc.exe -D_FILE_OFFSET_BITS=64
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----

meson.build:1:0: ERROR: Compiler ccache cc can not compile programs.

Huh, it's not a question of gcc vs cc, it's that meson automatically uses
ccache. And it looks like msys's ccache is broken at the moment (installed
yesterday):

$ ccache --version
ccache version 4.4.1
...

$ echo > test.c
$ ccache cc -c test.c
Segmentation fault (core dumped)
..

not sure how that leads to hanging, but it's not too surprising that things
don't work out after that...

Greetings,

Andres Freund

On 10/12/21 2:09 PM, Andres Freund wrote:

Hi,

On 2021-10-12 09:59:26 -0700, Andres Freund wrote:

On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:

It hung because it expected the compiler to be 'ccache cc'. Hanging in
such a case is kinda unforgivable. I remedied that by setting 'CC=gcc'
but it then errored out looking for perl libs. I think msys2 is going to
be a bit difficult here :-(

Hm. Yea, the perl thing is my fault - you should be able to get past it with
-Dperl=disabled, and I'll take a look at fixing the perl detection. (*)

This is a weird one. I don't know much about msys, so it's probably related to
that. Perl spits out /usr/lib/perl5/core_perl/ as its archlibexp. According to
shell commands that exists, but not according to msys's own python

$ /mingw64/bin/python -c "import os; p = '/usr/lib/perl5/core_perl/CORE'; print(f'does {p} exist:', os.path.exists(p))"
does /usr/lib/perl5/core_perl/CORE exist: False

$ ls -ld /usr/lib/perl5/core_perl/CORE
drwxr-xr-x 1 anfreund anfreund 0 Oct 10 10:19 /usr/lib/perl5/core_perl/CORE

Looks to me like a python issue:

# perl -e 'my $p = "/usr/lib/perl5/core_perl/CORE"; print qq(does $p
exist: ), -e $p, qq{\n};'
does /usr/lib/perl5/core_perl/CORE exist: 1

# python -c "import os; p = '/usr/lib/perl5/core_perl/CORE';
print(f'does {p} exist:', os.path.exists(p))"
does /usr/lib/perl5/core_perl/CORE exist: False

# cygpath -m /usr/lib/perl5/core_perl/CORE
C:/tools/msys64/usr/lib/perl5/core_perl/CORE

# python -c "import os; p =
'C:/tools/msys64/usr/lib/perl5/core_perl/CORE'; print(f'does {p}
exist:', os.path.exists(p))"
does C:/tools/msys64/usr/lib/perl5/core_perl/CORE exist: True

Clearly python is not understanding msys virtualized paths.

I guess I should figure out how to commandline install msys and add it to CI.

here's what I do:

# msys2 outputs esc-[3J which clears the screen's scroll buffer. Nasty.
# so we redirect the output
# find the log in c:\Windows\System32 if needed
choco install -y --no-progress --limit-output msys2 > msys2inst.log
c:\tools\msys64\usr\bin\bash -l
'/c/vfiles/windows-uploads/msys2-packages.sh'

Here's what's in msys-packages.sh:

pacman -S --needed --noconfirm \
    base-devel \
    msys/git \
    msys/ccache \
    msys/vim  \
    msys/perl-Crypt-SSLeay \
    mingw-w64-clang-x86_64-toolchain \
    mingw-w64-x86_64-toolchain

# could do: pacman -S --needed --noconfirm development
# this is more economical. These should cover most of the things you
might
# want to configure with

pacman -S --needed --noconfirm \
       msys/gettext-devel \
       msys/icu-devel \
       msys/libiconv-devel \
       msys/libreadline-devel \
       msys/libxml2-devel \
       msys/libxslt-devel \
       msys/openssl-devel \
       msys/zlib-devel

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 10/12/21 2:23 PM, Andres Freund wrote:

Hi,

On 2021-10-12 14:11:39 -0400, Andrew Dunstan wrote:

On 10/12/21 12:59 PM, Andres Freund wrote:

If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?

Here's the entire thing
Sanity check compiler command line: ccache cc sanitycheckc.c -o
sanitycheckc.exe -D_FILE_OFFSET_BITS=64
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----

meson.build:1:0: ERROR: Compiler ccache cc can not compile programs.

Huh, it's not a question of gcc vs cc, it's that meson automatically uses
ccache. And it looks like msys's ccache is broken at the moment (installed
yesterday):

$ ccache --version
ccache version 4.4.1
...

$ echo > test.c
$ ccache cc -c test.c
Segmentation fault (core dumped)
..

not sure how that leads to hanging, but it's not too surprising that things
don't work out after that...

Yes, I've had to disable ccache on fairywren.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Hi,

On 2021-10-12 09:15:41 -0700, Andres Freund wrote:

For example, at the time, gcc on macOS was not supported. Meson thought, if
you are on macOS, you are surely using the Apple compiler, and it supports
these options.

I'm pretty sure this one now can just be overridden with CC=gcc. It can on
linux and windows, but I don't have ready interactive access with a mac
(leaving cirrus asside, which now has a "start a terminal" option...).

It was a tad more complicated. But only because it took me a while to figure
out how to make gcc on macos actually work, independent of meson. Initially
gcc was always failing with errors about not finding the linker, and
installing binutils was a dead end.

Turns out just using a gcc at a specific path doesn't work, it ends up using
wrong internal binaries or something like that.

Once I got to that, the meson part was easy:

$ export PATH="/usr/local/opt/gcc/bin:$PATH"
$ CC=gcc-11 meson setup build-gcc
...
C compiler for the host machine: gcc-11 (gcc 11.2.0 "gcc-11 (Homebrew GCC 11.2.0) 11.2.0")
...
$ cd build-gcc
$ ninja test
...

181/181 postgresql:tap+subscription / subscription/t/100_bugs.pl OK 17.83s 5 subtests passed

Ok: 180
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 1
Timeout: 0

One thing that is nice with meson's testrunner is that it can parse the output
of tap tests and recognizes the number of completed / failed subtests. I
wonder whether we could make pg_regress' output tap compliant without the
output quality suffering too much.

Greetings,

Andres Freund

On 10/12/21 2:37 PM, Andrew Dunstan wrote:

On 10/12/21 2:09 PM, Andres Freund wrote:

Hi,

On 2021-10-12 09:59:26 -0700, Andres Freund wrote:

On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:

It hung because it expected the compiler to be 'ccache cc'. Hanging in
such a case is kinda unforgivable. I remedied that by setting 'CC=gcc'
but it then errored out looking for perl libs. I think msys2 is going to
be a bit difficult here :-(

Hm. Yea, the perl thing is my fault - you should be able to get past it with
-Dperl=disabled, and I'll take a look at fixing the perl detection. (*)

This is a weird one. I don't know much about msys, so it's probably related to
that. Perl spits out /usr/lib/perl5/core_perl/ as its archlibexp. According to
shell commands that exists, but not according to msys's own python

$ /mingw64/bin/python -c "import os; p = '/usr/lib/perl5/core_perl/CORE'; print(f'does {p} exist:', os.path.exists(p))"
does /usr/lib/perl5/core_perl/CORE exist: False

$ ls -ld /usr/lib/perl5/core_perl/CORE
drwxr-xr-x 1 anfreund anfreund 0 Oct 10 10:19 /usr/lib/perl5/core_perl/CORE

Looks to me like a python issue:

# perl -e 'my $p = "/usr/lib/perl5/core_perl/CORE"; print qq(does $p
exist: ), -e $p, qq{\n};'
does /usr/lib/perl5/core_perl/CORE exist: 1

# python -c "import os; p = '/usr/lib/perl5/core_perl/CORE';
print(f'does {p} exist:', os.path.exists(p))"
does /usr/lib/perl5/core_perl/CORE exist: False

# cygpath -m /usr/lib/perl5/core_perl/CORE
C:/tools/msys64/usr/lib/perl5/core_perl/CORE

# python -c "import os; p =
'C:/tools/msys64/usr/lib/perl5/core_perl/CORE'; print(f'does {p}
exist:', os.path.exists(p))"
does C:/tools/msys64/usr/lib/perl5/core_perl/CORE exist: True

Clearly python is not understanding msys virtualized paths.

It's a matter of which python you use. The one that understands msys
paths is msys/python. The mingw64 packages are normally pure native
windows and so don't understand msys paths. I know it's confusing :-(

# /usr/bin/python -c "import os; p = '/usr/lib/perl5/core_perl/CORE';
print(f'does {p} exist:', os.path.exists(p))"
does /usr/lib/perl5/core_perl/CORE exist: True

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Hi,

On 2021-10-12 14:37:04 -0400, Andrew Dunstan wrote:

On 10/12/21 2:09 PM, Andres Freund wrote:

Hm. Yea, the perl thing is my fault - you should be able to get past it with
-Dperl=disabled, and I'll take a look at fixing the perl detection. (*)

This is a weird one. I don't know much about msys, so it's probably related to
that. Perl spits out /usr/lib/perl5/core_perl/ as its archlibexp. According to
shell commands that exists, but not according to msys's own python

$ /mingw64/bin/python -c "import os; p = '/usr/lib/perl5/core_perl/CORE'; print(f'does {p} exist:', os.path.exists(p))"
does /usr/lib/perl5/core_perl/CORE exist: False

$ ls -ld /usr/lib/perl5/core_perl/CORE
drwxr-xr-x 1 anfreund anfreund 0 Oct 10 10:19 /usr/lib/perl5/core_perl/CORE

Looks to me like a python issue:

Clearly python is not understanding msys virtualized paths.

Ah, it's a question of the *wrong* python being used :/. I somehow ended up
with both a mingw and an msys python, with the mingw python taking preference
over the msys one. The latter one does understand such paths.

I guess I should figure out how to commandline install msys and add it to CI.

here's what I do:

Thanks!

Does that recipe get you to a build where ./configure --with-perl succeeds?

I see this here:

checking for Perl archlibexp... /usr/lib/perl5/core_perl
checking for Perl privlibexp... /usr/share/perl5/core_perl
checking for Perl useshrplib... true
checking for CFLAGS recommended by Perl... -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -march=x86-64 -mtune=generic -O2 -pipe -fwrapv -fno-strict-aliasing -fstack-protector-strong
checking for CFLAGS to compile embedded Perl... -DPERL_USE_SAFE_PUTENV
checking for flags to link embedded Perl... no
configure: error: could not determine flags for linking embedded Perl.
This probably means that ExtUtils::Embed or ExtUtils::MakeMaker is not
installed.

If I just include perl.h from a test file with gcc using the above flags it
fails to compile:
$ echo '#include <perl.h>' > test.c
$ gcc -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -march=x86-64 -mtune=generic -O2 -pipe -fwrapv -fno-strict-aliasing -fstack-protector-strong test.c -c -I /c/dev/msys64/usr/lib/perl5/core_perl/CORE
In file included from test.c:1:
C:/dev/msys64/usr/lib/perl5/core_perl/CORE/perl.h:1003:13: fatal error: sys/wait.h: No such file or directory
1003 | # include <sys/wait.h>

and ldopts bleats

$ perl -MExtUtils::Embed -e ldopts
Warning (mostly harmless): No library found for -lpthread
Warning (mostly harmless): No library found for -ldl
-Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong -L/usr/lib/perl5/core_perl/CORE -lperl -lcrypt

Greetings,

Andres Freund