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 1rlWO7-002sfA-0R for pgsql-bugs@arkaria.postgresql.org; Sat, 16 Mar 2024 15:55:59 +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 1rlWO5-00GTGB-18 for pgsql-bugs@arkaria.postgresql.org; Sat, 16 Mar 2024 15:55:57 +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 1rlWO4-00GTG3-Kg for pgsql-bugs@lists.postgresql.org; Sat, 16 Mar 2024 15:55:57 +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 1rlWO0-004pxr-J1 for pgsql-bugs@lists.postgresql.org; Sat, 16 Mar 2024 15:55:55 +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 418F0E1A01B1; Sat, 16 Mar 2024 16:55:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technowledgy.de; s=kas202308201259; t=1710604550; bh=i5aNEeC0iMdNZkgmtOdscyC99vvOgjMk52vfPdInqDs=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=PL+dQ/XLrDKz6/cENzqEmqo7jRyxOXMxMq89iFvritJmL6cLev5RbNIhY0F7Xbvn0 o23W32NsDfmtN3EQPvjByIAn5Yqb+ilQTIjF9/121Gz0J/5yWxUrtcpPghLuW+MF9b AEHXYX8KvA7iID9ZSS3U+r1kmb1TzS+yM3ySdzxHv9NmWt0Op2TcZ8Ib0X4r6QcSVx 2WVMctLN8ByvB18jx1a6LslXaiZ1y7HtLm+iJ932jDHobHk6NOAOU+1lEizNHxQ0ME 6iGnv8B7k1padF3piDvEKOvu6poezgiz63dZ+HyQkN/k9EpF+uIkcxgX7XewyVVAZj ER1iyYO5dymEg== Content-Type: multipart/mixed; boundary="------------jYNpA0rRr19SOJ3Fv8wmcl5a" Message-ID: <443da167-ee01-47d2-9c83-105694b4cbd5@technowledgy.de> Date: Sat, 16 Mar 2024 16:55:49 +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: Tom Lane Cc: PostgreSQL Bugs References: <2852940.1710599083@sss.pgh.pa.us> In-Reply-To: <2852940.1710599083@sss.pgh.pa.us> X-Spamd-Bar: ++++++++ X-Spam: Yes List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Tom Lane: > Why do you think this is our bug and not musl's? Because I tried to reproduce with musl directly with a very simple example as mentioned in: > To rule out a musl bug, I also put together a very simple test-case of an executable loading liba with dlopen(), which depends on libb and then constructing the same scenario with LD_LIBRARY_PATH. This works fine when compiled with glibc and musl, too. Thus, I believe the problem to be somewhere in how postgres loads those libraries. My test case looked like the attached. To compile it with musl via Dockerfile: docker build . -t musl-dlopen && docker run --rm musl-dlopen a.c/a.h is equivalent to libpqwalreceiver and b.c/b.h to libpq. This works fine with both musl and glibc. (Note: I also tried putting liba.so and libb.so in different folders, adding both to LD_LIBRARY_PATH - but that worked fine as well.) Now my very simple example probably does something different than postgres, so that the problem doesn't appear there. But since it seems possible to do this with musl in principle, it should be possible to do it differently in postgres to make it work, too. Any ideas? Best, Wolfgang --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: text/x-csrc; charset=UTF-8; name="a.c" Content-Disposition: attachment; filename="a.c" Content-Transfer-Encoding: base64 I2luY2x1ZGUgImEuaCIKI2luY2x1ZGUgImIuaCIKI2luY2x1ZGUgPHN0ZGlvLmg+Cgp2b2lk IGEoKSB7CiAgcHJpbnRmKCJhIik7CiAgYigpOwp9Cg== --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: text/x-chdr; charset=UTF-8; name="a.h" Content-Disposition: attachment; filename="a.h" Content-Transfer-Encoding: base64 dm9pZCBhKCk7Cg== --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: text/x-csrc; charset=UTF-8; name="b.c" Content-Disposition: attachment; filename="b.c" Content-Transfer-Encoding: base64 I2luY2x1ZGUgImIuaCIKI2luY2x1ZGUgPHN0ZGlvLmg+Cgp2b2lkIGIoKSB7CiAgcHJpbnRm KCJiIik7Cn0K --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: text/x-chdr; charset=UTF-8; name="b.h" Content-Disposition: attachment; filename="b.h" Content-Transfer-Encoding: base64 dm9pZCBiKCk7Cg== --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: text/plain; charset=UTF-8; name="Dockerfile" Content-Disposition: attachment; filename="Dockerfile" Content-Transfer-Encoding: base64 RlJPTSBhbHBpbmUKClJVTiBhcGsgYWRkIGJ1aWxkLWJhc2UKCldPUktESVIgL3Vzci9zcmMK Q09QWSAuIC91c3Ivc3JjClJVTiAuL3Rlc3Quc2gKCkVOViBMRF9MSUJSQVJZX1BBVEg9LgpF TlRSWVBPSU5UIC91c3Ivc3JjL21haW4K --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: text/x-csrc; charset=UTF-8; name="main.c" Content-Disposition: attachment; filename="main.c" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPGRsZmNu Lmg+CgppbnQgbWFpbihpbnQgYXJnYywgY2hhciogYXJndltdKSB7CiAgdm9pZCAqaGFuZGxl ID0gZGxvcGVuKCJsaWJhLnNvIiwgUlRMRF9OT1cgfCBSVExEX0dMT0JBTCk7CiAgaWYgKCFo YW5kbGUpIHsKICAgIGZwcmludGYoc3RkZXJyLCAiZGxvcGVuIGZhaWxlZDogJXNcbiIsIGRs ZXJyb3IoKSk7CiAgfQoKICB2b2lkICgqZnVuY190KSh2b2lkKTsKICAqKHZvaWQgKiopICgm ZnVuY190KSA9IGRsc3ltKGhhbmRsZSwgImEiKTsKICAoKmZ1bmNfdCkoKTsgIAp9Cg== --------------jYNpA0rRr19SOJ3Fv8wmcl5a Content-Type: application/x-shellscript; name="test.sh" Content-Disposition: attachment; filename="test.sh" Content-Transfer-Encoding: base64 IyEvdXNyL2Jpbi9lbnYgc2gKc2V0IC1lCgpnY2MgLWcgLXNoYXJlZCBiLmMgLVdsLC1zb25h bWU9bGliYi5zbyAtSS4gLW8gbGliYi5zbwpnY2MgLWcgLXNoYXJlZCBhLmMgLVdsLC1zb25h bWU9bGliYS5zbyAtSS4gLWxiIC1MLiAtbyBsaWJhLnNvCmdjYyAtZyBtYWluLmMgLUkuIC1v IG1haW4gLWxkbAoKTERfTElCUkFSWV9QQVRIPS4gLi9tYWluCg== --------------jYNpA0rRr19SOJ3Fv8wmcl5a--