Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFvOe-0005P6-Uq for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jul 2022 10:33:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oFvOd-0006k6-MG for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jul 2022 10:33:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFvOd-0006jK-Ci for pgsql-hackers@lists.postgresql.org; Mon, 25 Jul 2022 10:33:07 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFvOa-00019t-7P for pgsql-hackers@postgresql.org; Mon, 25 Jul 2022 10:33:06 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id D5C8A3200A34; Mon, 25 Jul 2022 06:33:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 25 Jul 2022 06:33:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1658745179; x=1658831579; bh=k +7I9KWQIZLoT2rPbcCn5TTG0QkNy71ueKVKY3RGfPw=; b=XZ6b0StolUV7C19Q3 Bozz0xH99Db3l3pVAUvPyS5vaalBUgiRqQAj9Ns28+OTZQYVe29vmz5GoCZIfu96 hFR/9WOCDXjccrurpXVy966vR2R4ZAi2Q35o8P7mUnwSd6QFlewZcPp3P2rDviI8 3QsmfsU6Z876v++4pC8G72Cuuy2uXomNuwDMvAUd0iXbsT69/n49GYWIIWUomp6o vEe/4L3UhQVXcQPbDG2FAEqrWlu8jxs/Uk1Bkt8bEG3uErQkDpdzm0wyAPtzlvua Q9kYsxwLI2RK0x0uM0OxtjC8w1enG+PEYSpIw1+acZvEEqsi125HuH6SC2BKZhSn uy7yA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvddtkedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Jul 2022 06:32:58 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 6E2E2369; Mon, 25 Jul 2022 12:32:55 +0200 (CEST) Date: Mon, 25 Jul 2022 12:32:55 +0200 From: Alvaro Herrera To: Tom Lane Cc: Andrew Dunstan , Justin Pryzby , pgsql-hackers@postgresql.org, Andres Freund Subject: Re: make -C libpq check fails obscurely if tap tests are disabled Message-ID: <20220725103255.fmt5xftm3ip4sgij@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <774726.1658533802@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jul-22, Tom Lane wrote: > Barring objections, I'll push the attached patch. I suppose we > could undo whatever dumbing-down was done in _create_recursive_target, > but is it worth troubling with? Excellent, many thanks. I tried to get Make 3.80 built here, to no avail. I have updated that to 3.81, but still haven't found a way past the automake phase. Anyway, I tried a revert of 1bd201214965 -- I ended up with the attached. However, while a serial compile fails, parallel ones fail randomly, and apparently because two submakes compete in building libpq.a and each deletes the other's file. What I think this is saying is that the 3.80-induced wording of that function limits concurrency of the generated recursive rules, which prevents the problem from occurring; and if we were to fix that bug we would probably end up with more concurrency. Here's the bottom of the 'make -j8' log: rm -f libpq.a ranlib libpq.a ranlib: 'libpq.a': No such file make[5]: *** [/pgsql/source/master/src/Makefile.shlib:261: libpq.a] Error 1 make[5]: *** Waiting for unfinished jobs.... ar crs libpq.a fe-auth-scram.o fe-connect.o fe-exec.o fe-lobj.o fe-misc.o fe-print.o fe-protocol3.o fe-secure.o fe-trace.o legacy-pqsignal.o libpq-events.o pqexpbuffer.o fe-auth.o fe-secure-common.o fe-secure-openssl.o ranlib libpq.a touch libpq.a rm -f libpq.so.5 ln -s libpq.so.5.16 libpq.so.5 rm -f libpq.so ln -s libpq.so.5.16 libpq.so touch libpq-refs-stamp rm -f libpq.so.5 ln -s libpq.so.5.16 libpq.so.5 rm -f libpq.so ln -s libpq.so.5.16 libpq.so rm -f libpq.so.5 ln -s libpq.so.5.16 libpq.so.5 touch libpq-refs-stamp rm -f libpq.so gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O2 -pthread -D_REENTRANT -D_THREAD_SAFE -fPIC -shared -Wl,-soname,libecpg.so.6 -Wl,--version-script=exports.list -o libecpg.so.6.16 connect.o data.o descriptor.o error.o execute.o memory.o misc.o prepare.o sqlda.o typename.o -L../../../../src/port -L../../../../src/common -L../pgtypeslib -lpgtypes -L../../../../src/common -lpgcommon_shlib -L../../../../src/port -lpgport_shlib -L../../../../src/interfaces/libpq -lpq -L/usr/lib/llvm-11/lib -Wl,--as-needed -Wl,-rpath,'/pgsql/install/master/lib',--enable-new-dtags -lm ln -s libpq.so.5.16 libpq.so rm -f libecpg.a make[4]: *** [../../../../src/Makefile.global:618: submake-libpq] Error 2 ar crs libecpg.a connect.o data.o descriptor.o error.o execute.o memory.o misc.o prepare.o sqlda.o typename.o make[3]: *** [Makefile:17: all-ecpglib-recursive] Error 2 make[3]: *** Waiting for unfinished jobs.... ranlib libecpg.a touch libecpg.a rm -f libecpg.so.6 ln -s libecpg.so.6.16 libecpg.so.6 rm -f libecpg.so ln -s libecpg.so.6.16 libecpg.so gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O2 -pthread -D_REENTRANT -D_THREAD_SAFE -fPIC -shared -Wl,-soname,libecpg_compat.so.3 -Wl,--version-script=exports.list -o libecpg_compat.so.3.16 informix.o -L../../../../src/port -L../../../../src/common -L../ecpglib -lecpg -L../pgtypeslib -lpgtypes -L../../../../src/common -lpgcommon_shlib -L../../../../src/port -lpgport_shlib -L../../../../src/interfaces/libpq -lpq -L/usr/lib/llvm-11/lib -Wl,--as-needed -Wl,-rpath,'/pgsql/install/master/lib',--enable-new-dtags -lm rm -f libecpg_compat.a ar crs libecpg_compat.a informix.o ranlib libecpg_compat.a touch libecpg_compat.a rm -f libecpg_compat.so.3 ln -s libecpg_compat.so.3.16 libecpg_compat.so.3 rm -f libecpg_compat.so ln -s libecpg_compat.so.3.16 libecpg_compat.so make[2]: *** [Makefile:17: all-ecpg-recursive] Error 2 make[1]: *** [Makefile:42: all-interfaces-recursive] Error 2 make: *** [GNUmakefile:11: all-src-recursive] Error 2 -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Los dioses no protegen a los insensatos. Éstos reciben protección de otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)