Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1voplK-00EXHq-2D for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Feb 2026 21:22:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vopkI-0078J2-2W for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Feb 2026 21:21:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vopkI-0078Iu-1Z for pgsql-hackers@lists.postgresql.org; Sat, 07 Feb 2026 21:21:38 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vopkF-000000012Vc-29rU for pgsql-hackers@lists.postgresql.org; Sat, 07 Feb 2026 21:21:36 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 617LLVPT2471230; Sat, 7 Feb 2026 16:21:31 -0500 From: Tom Lane To: pgsql-hackers@lists.postgresql.org cc: Greg Burd Subject: Meson vs. Solaris MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <2471158.1770499261.0@sss.pgh.pa.us> Date: Sat, 07 Feb 2026 16:21:31 -0500 Message-ID: <2471229.1770499291@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2471158.1770499261.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable I wondered why Greg Burd's new buildfarm animal "icarus" hasn't yet managed to complete a successful run. The symptoms suggest that getopt() isn't doing what we want: /scratch/build/HEAD/pgsql.build/tmp_install/scratch/build/HEAD/inst/bin/po= stgres: illegal option -- cluster-name=3Dnode1 Try "postgres --help" for more information. But we have other BF animals running on OpenIndiana (Solaris) without trouble. On investigation, it seems that Greg is the first to try to use the meson build system on Solaris, and it doesn't work. Our Autoconf infrastructure knows that we should use our own getopt() because Solaris's doesn't do what we want. meson.build did try to copy that logic: always_replace_getopt =3D host_system in ['windows', 'cygwin', 'openbsd', = 'solaris'] However, as seen elsewhere in that file, 'solaris' is not the value of host_system on this platform! It's 'sunos'. So we are trying to use the system's getopt(), and then the failure is completely expected. I've verified on a local OpenIndiana VM that the attached patch makes it work. Also, a quick grep doesn't find any other cases of the same error in our meson.build files. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="solaris.patch"; charset="us-ascii" Content-ID: <2471158.1770499261.2@sss.pgh.pa.us> Content-Description: solaris.patch Content-Transfer-Encoding: quoted-printable diff --git a/meson.build b/meson.build index df907b62da3..96b3869df86 100644 --- a/meson.build +++ b/meson.build @@ -2911,7 +2911,7 @@ gnugetopt_dep =3D cc.find_library('gnugetopt', requi= red: false) # (i.e., allow '-' as a flag character), so use our version on those pl= atforms # - We want to use system's getopt_long() only if the system provides str= uct # option -always_replace_getopt =3D host_system in ['windows', 'cygwin', 'openbsd',= 'solaris'] +always_replace_getopt =3D host_system in ['windows', 'cygwin', 'openbsd',= 'sunos'] always_replace_getopt_long =3D host_system in ['windows', 'cygwin'] or no= t cdata.has('HAVE_STRUCT_OPTION') = # Required on BSDs ------- =_aaaaaaaaaa0--