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.94.2) (envelope-from ) id 1rlqIV-004UVk-Ja for pgsql-bugs@arkaria.postgresql.org; Sun, 17 Mar 2024 13:11:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rlqIU-00Aqyp-4o for pgsql-bugs@arkaria.postgresql.org; Sun, 17 Mar 2024 13:11:30 +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.94.2) (envelope-from ) id 1rlqIT-00Aqyg-Ns for pgsql-bugs@lists.postgresql.org; Sun, 17 Mar 2024 13:11:30 +0000 Received: from dd25110.kasserver.com ([85.13.146.49]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rlqIO-004yr5-4T for pgsql-bugs@lists.postgresql.org; Sun, 17 Mar 2024 13:11:28 +0000 Received: from [192.168.0.101] (ip-037-201-153-175.um10.pools.vodafone-ip.de [37.201.153.175]) by dd25110.kasserver.com (Postfix) with ESMTPSA id 950D3E1A0089; Sun, 17 Mar 2024 14:11:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technowledgy.de; s=kas202308201259; t=1710681081; bh=lgeqHUyWX35tPTb14ISoD26eBrhs/kk9S2FwSbmxmQ4=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=JfrF5BByLftseQU1ODDmpDgNzQWG7VUv2hEm0GILHHK9FrGWgI5Wld+5gBe8N5hE8 JsWWR9IPTh3LMRJUvflX5hgr2mg63DroAc3m15yzyEJx1P6WvYog7AOI7hPgplwFfJ MKVAlh1sgoVA5oZxfR93b4KGDHpw8UAfMaF0MTmWnSgJhogS/RdDkSEjp7aRTY9b26 C1yiwruQTPAJEBKnnPRaO/plPmlIKLkUoW9nS90W7JLgWrdHvomSFPImJ18LmpbFqG WyuDlmwn9NlVjEoNMZQyKj89h0BHlm1LLUPhhE+H8hymcVBfzSvxjKfHeV11ID29UB /jhYV5G1tfjhA== Message-ID: <855a1b16-0dc0-42b2-8f90-79eb49cf2893@technowledgy.de> Date: Sun, 17 Mar 2024 14:11:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Wolfgang Walther Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded Content-Language: en-US To: Christophe Pettus Cc: Thomas Munro , Tom Lane , PostgreSQL Bugs References: <2852940.1710599083@sss.pgh.pa.us> <443da167-ee01-47d2-9c83-105694b4cbd5@technowledgy.de> <68C88EE3-CDCB-4993-9173-3A773F491F3A@thebuild.com> In-Reply-To: <68C88EE3-CDCB-4993-9173-3A773F491F3A@thebuild.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: + List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Christophe Pettus: > Given the musl (still?) does not define a preprocessor macro specific to it, is there a way of improving the test in pg_status.c to catch this case? It seems wrong that the current test passes a case that doesn't actually work. The missing macro is on purpose and unlikely to change: https://openwall.com/lists/musl/2013/03/29/13 I also found this thread, which discusses exactly our case: https://www.openwall.com/lists/musl/2022/08/17/1 Some quotes from that thread: > I understand that what Postgres et al are doing is a nasty hack. And: > Applications that *really* want setproctitle type functionality can > presumably do something like re-exec themselves with a suitably large > argv[0] to give them safe space to overwrite with their preferred > message, rather than UB trying to relocate the environment (and auxv? > how? they can't tell libc they moved it) to some other location. Could that be a more portable way of doing this? Best, Wolfgang