From unknown Sat Jun 14 03:57:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49232: load-foreign-library does not find versioned .so files Resent-From: =?UTF-8?Q?S=C3=B6ren?= Tempel Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 26 Jun 2021 12:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 49232 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: 49232@debbugs.gnu.org X-Debbugs-Original-To: bug-guile@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.1624709281830 (code B ref -1); Sat, 26 Jun 2021 12:08:01 +0000 Received: (at submit) by debbugs.gnu.org; 26 Jun 2021 12:08:01 +0000 Received: from localhost ([127.0.0.1]:47202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lx76M-0000DI-8x for submit@debbugs.gnu.org; Sat, 26 Jun 2021 08:08:01 -0400 Received: from lists.gnu.org ([209.51.188.17]:37486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lx6dD-0007tc-Pb for submit@debbugs.gnu.org; Sat, 26 Jun 2021 07:37:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lx6dD-00067B-Hn for bug-guile@gnu.org; Sat, 26 Jun 2021 07:37:51 -0400 Received: from magnesium.8pit.net ([45.76.88.171]:11643) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lx6dA-0001jL-TZ for bug-guile@gnu.org; Sat, 26 Jun 2021 07:37:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=opensmtpd; bh=Bxq74njpCu GYAzNJicheYgeiVfWYEsEwp8YpR4lQpko=; h=from:subject:to:date; d=soeren-tempel.net; b=I+IMl4KHdCJum59ZsMmlA8L9dMyfpIWD1yRqHhzDGhwvbwg Gplq8UGJz3Xr/zVymBYxWe85vs17cWJaeREypZjQJ4nIysry5xeFgNL70a5QDBY5Nv6hNe pksLoeWY1xQKmCaRCDz4XbNU98N6JHGfWozucsmr152S3lwGDBnUEM= Received: from localhost (p200300f5Ff11cC00FEB73078e72fd50B.dip0.t-ipconnect.de [2003:f5:ff11:cc00:feb7:3078:e72f:d50b]) by magnesium.8pit.net (OpenSMTPD) with ESMTPSA id 1d810ebd (TLSv1.3:AEAD-AES256-GCM-SHA384:256:YES) for ; Sat, 26 Jun 2021 13:37:40 +0200 (CEST) Date: Sat, 26 Jun 2021 13:37:31 +0200 From: =?UTF-8?Q?S=C3=B6ren?= Tempel Message-Id: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=45.76.88.171; envelope-from=soeren@soeren-tempel.net; helo=magnesium.8pit.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Mailman-Approved-At: Sat, 26 Jun 2021 08:07:56 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, Many Linux distributions (e.g. Alpine Linux and Debian) split packages into multiple subpackages. For instance, library development headers are usually separated from .so files since the former are commonly not needed as a run-time dependency. As part of this split, only versioned sonames are commonly provided by library packages (e.g. libexample.so.4.2.0), the symbolic link to the current .so (e.g. libexample.so -> libexample.so.4.2.0) is provided in a separate development subpackage for every library. This is done to ensure that the unversioned .so symbolic link is only used during compilation, for loading purposes a versioned .so name should always be used. This eases rebuilding packages on ABI changes (i.e. soname version bumps). Many scripting languages, e.g. python, implement a fuzzy search in their FFI library to also match .so files with version numbers [1]. Unfortunately, guile's load-foreign-library does not do so. That is, (load-foreign-library "libexample") will only match libexample.so but not libexample.so.4.2.0. As a consequence, guile packages using FFI will always require a run-time dependency on development subpackages (including headers), only for the .so symbolic link, which is very inconvenient for us at Alpine [2]. Would it be possible to modify load-foreign-library to also match .so file names with a version postfix (like python does for instance)? Please CC me, I am not subscribed to the list. Greetings, S=C3=B6ren [1]: https://docs.python.org/3/library/ctypes.html?highlight=3Dfind_library= #ctypes.util.find_library [2]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12783 From unknown Sat Jun 14 03:57:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49232: [PATCH] load-foreign-library: perform substring match on library files Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 23 Jul 2022 13:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49232 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: soeren@soeren-tempel.net, 49232@debbugs.gnu.org Cc: guile-devel@gnu.org X-Debbugs-Original-To: soeren@soeren-tempel.net, bug-guile@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16585822583403 (code B ref -1); Sat, 23 Jul 2022 13:18:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Jul 2022 13:17:38 +0000 Received: from localhost ([127.0.0.1]:43791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFF0k-0000so-1O for submit@debbugs.gnu.org; Sat, 23 Jul 2022 09:17:38 -0400 Received: from lists.gnu.org ([209.51.188.17]:47890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFF0h-0000se-L1 for submit@debbugs.gnu.org; Sat, 23 Jul 2022 09:17:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFF0e-0001kS-HJ for bug-guile@gnu.org; Sat, 23 Jul 2022 09:17:35 -0400 Received: from xavier.telenet-ops.be ([2a02:1800:120:4::f00:14]:52116) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFF0a-0000le-OA for bug-guile@gnu.org; Sat, 23 Jul 2022 09:17:31 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by xavier.telenet-ops.be with bizsmtp id ydHQ2700820ykKC01dHRU4; Sat, 23 Jul 2022 15:17:25 +0200 Message-ID: <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be> Date: Sat, 23 Jul 2022 15:17:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> <20220723110919.30107-1-soeren@soeren-tempel.net> From: Maxime Devos In-Reply-To: <20220723110919.30107-1-soeren@soeren-tempel.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------lzr087glQbV3cTXzmjKjGidU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1658582245; bh=UJua61u+gqCuFteIxjGrzMVxHrZ9+c+sJ8IPcSRsnp8=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=aCQpc1Zo9Cp6sVOXG1Sd/s2JB9QHTGbXh8boDXAjNU06d1MUv15rALNFKIUV/AlIA fw3ASRuBUIW7uzJpkq4pNs+5lM/6/GeD1Pwgy2EmfjMcT+R35oKDdV9q2SKEl9KzGo hDuWBlTRYubyxkBEL0PoY4tazUOowNgTaJH5Iq47mlAXKTbopUIUohI1PigpQo7c3P Ea9GALKfs1V9hIh0+jcAunYbjAi8vpKtc3pbP9nb5zyosCpgYlA1Yt54yWobYF8sMq aUQa6EjtwU5io1rPUhhIh8HVJPq5EVwaLjQffUROCau/UJ87qQcgL7te5imtpZJKzn hCNmPATFHwHUQ== Received-SPF: pass client-ip=2a02:1800:120:4::f00:14; envelope-from=maximedevos@telenet.be; helo=xavier.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------lzr087glQbV3cTXzmjKjGidU Content-Type: multipart/mixed; boundary="------------I6tQcbRO09NW77TqhkF0Hfwq"; protected-headers="v1" From: Maxime Devos To: soeren@soeren-tempel.net, bug-guile@gnu.org Cc: guile-devel@gnu.org Message-ID: <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be> Subject: Re: [PATCH] load-foreign-library: perform substring match on library files References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> <20220723110919.30107-1-soeren@soeren-tempel.net> In-Reply-To: <20220723110919.30107-1-soeren@soeren-tempel.net> --------------I6tQcbRO09NW77TqhkF0Hfwq Content-Type: multipart/mixed; boundary="------------E6Yf2tdnFB135m1JzBI6K4p3" --------------E6Yf2tdnFB135m1JzBI6K4p3 Content-Type: multipart/alternative; boundary="------------jVyWv6k2lftF6ZZEcSNY3zd7" --------------jVyWv6k2lftF6ZZEcSNY3zd7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAyMy0wNy0yMDIyIDEzOjA5LCBzb2VyZW5Ac29lcmVuLXRlbXBlbC5uZXQgd3JvdGU6 DQo+IEZyb206IFPDtnJlbiBUZW1wZWw8c29lcmVuQHNvZXJlbi10ZW1wZWwubmV0Pg0KPg0K PiBUaGlzIHBhdGNoIGlzIGEgZml4IGZvciBidWcgIzQ5MjMyIFsxXS4gVG8gc3VtbWFyaXpl IHRoaXMgYnVnLCB0aGUNCj4gY3VycmVudCBsb2FkLWZvcmVpZ24tbGlicmFyeSBpbXBsZW1l bnRhdGlvbiBkb2VzIG5vdCBsb2FkIHZlcnNpb25lZA0KPiBzb25hbWVzIChlLmcuIGxpYmZv by5zby41KSB3aGljaCBhcmUgY29tbW9uIG9uIExpbnV4LiBUaGlzIGlzIGFuIGlzc3VlDQo+ IGZvciB1cyBhdCBBbHBpbmUgTGludXggc2luY2Ugd2Ugc2hpcCB1bnZlcnNpb25lZCBzb25h bWVzIChlLmcuIGxpYmZvby5zbykNCj4gc2VwYXJhdGVseS4gUGxlYXNlIHJlZmVyIHRvIHRo ZSBvcmlnaW5hbCBidWcgcmVwb3J0IGZvciBkZXRhaWxzLg0KPiAgIFsuLi5dDQoNCkxvbmcg dGVybSwgSSB0aGluayBpdCB3b3VsZCBiZSBpZGVhbCBmb3IgR3VpbGUgdG8gZGVjaWRlIHVw b24gYSBtYWpvciANCnZlcnNpb24gKGFuZCBtYXliZSBldmVuIGxvY2F0aW9uLCBkZXBlbmRp bmcgb24gdGhlIGNob2ljZXMgb2YgdGhlIA0KZGlzdHJvKSBhdCBfY29tcGlsZV8gdGltZSBp bnN0ZWFkIG9mIHJ1bnRpbWUsIG5vdCB1bmxpa2UgaG93IG90aGVyIA0KY29tcGlsZXJzIHdv cmsuDQoNCk1vcmUgY29uY3JldGVseSwgd2UgY291bGQgaGF2ZSBhIG1hY3JvICdsaW5rLWZv cmVpZ24tbGlicmFyeScsIG9mIHRoZSBmb3JtOg0KDQoobGluay1mb3JlaWduLWxpYnJhcnkg bGlicmFyeSBbbWF5YmUgb3RoZXIgYXJndW1lbnRzKS4NCg0KSWYgdGhlIEd1aWxlIG1vZHVs ZSBpcyBiZWluZyBjb21waWxlZCB3aXRoIC0tcnBhdGgsIGl0IHNlYXJjaGVzIA0KJENST1NT X0xJQlJBUllfUEFUSCBvciAkTElCUkFSWV9QQVRIIGFuZCBlbmNvZGVzIHRoZSBmdWxsIGZp bGUgbmFtZSANCigvdXNyL2xpYi8uLi4vbGliZ3VpbGUtLi4uIG9yIC9nbnUvc3RvcmUvLi4u L2xpYi8uLi4pIGluIHRoZSAuZ28sIHdoaWNoIA0KYXZvaWRzIHNvbWUgbWFudWFsIHBhdGNo aW5nIHdlIGhhdmUgdG8gZG8gaW4gR3VpeC4NCg0KSXQgY291bGQgYWxzbyBkZXRlY3QgaWYg aXQncyBsb2FkaW5nIGEgbGliZm9vLnNvIHBvaW50aW5nIHRvIA0KbGliZm9vLnNvLk4sIGFu ZCBpZiBzbywgcmVwbGFjZSBsaWJmb28uc28gYnkgbGliZm9vLnNvLk4uDQoNClRoZSBmb3Jt ZXIgKHJwYXRoKSB3b3VsZCB3b3JrIGZvciBHdWl4LCBhbmQgSSBleHBlY3QgdGhlIGxhdHRl ciANCihsaWJmb28uc28gLT4gbGliZm9vLnNvLk4pIHRvIHdvcmsgb24gQWxwaW5lLg0KDQo+ ICsoZGVmaW5lIChmaWxlLWV4aXN0cy1pbi1kaXItd2l0aC1leHRlbnNpb24gZGlyIGJhc2Vu YW1lIGV4dHMpDQo+ICsgIChsZXQqICgoZGlyLXN0cmVhbSAob3BlbmRpciBkaXIpKQ0KPiAr ICAgICAgICAgKHJldCAobGV0IGxvb3AgKChmbiAocmVhZGRpciBkaXItc3RyZWFtKSkpDQo+ ICsgICAgICAgICAgICAgICAgKGFuZCAobm90IChlb2Ytb2JqZWN0PyBmbikpDQo+ICsgICAg ICAgICAgICAgICAgICAgICAoaWYgKGZpbGVuYW1lLW1hdGNoZXMtd2l0aC1leHRlbnNpb24/ IGZuIGJhc2VuYW1lIGV4dHMpDQo+ICsgICAgICAgICAgICAgICAgICAgICAgIChpbi12aWNp bml0eSBkaXIgZm4pDQo+ICsgICAgICAgICAgICAgICAgICAgICAgIChsb29wIChyZWFkZGly IGRpci1zdHJlYW0pKSkpKSkpDQpJSVVDLCB0aGUgc3RyaW5nLXByZWZpeD8gc2VhcmNoIGlz IG5vbi1kZXRlcm1pbmlzdGljLCB3aGljaCBjYW4gbWFrZSANCmRlYnVnZ2luZyBjb21wbGlj YXRlZCB3aGVuIG11bHRpcGxlIHZlcnNpb25zIGFyZSBpbnN0YWxsZWQuIEkgdGhpbmsgaXQg DQp3b3VsZCBiZSBiZXR0ZXIgdG8gYmFpbCBvdXQgaWYgdGhlcmUgYXJlIG11bHRpcGxlIG1h dGNoZXMgaW5zdGVhZCBvZiBhIA0KcmlzayBvZiBndWVzc2luZyBpbmNvcnJlY3RseS4NCg0K VGhlIHByZWZpeGluZyBiZWhhdmlvdXIgaXMgYWxzbyBub3QgZG9jdW1lbnRlZCwgc28gc29t ZSBkb2N1bWVudGF0aW9uIGlzIA0KbmVlZGVkIGluIHRoZSBtYW51YWwuDQoNClF1ZXN0aW9u czoNCg0KICAqIERvZXMgaXQgZ28gc2Nhbm5pbmcgdGhlIGRpciBldmVuIGlmIGxpYmZvby5z byBjb3VsZCBiZSBmb3VuZD8NCiAgICBPdGhlcndpc2UsIHRoZXJlIGFyZSBzb21lIHBvc3Np YmxlIHBlcmZvcm1hbmNlIGdhaW5zIGJ5IGNoZWNraW5nIGZvcg0KICAgIGxpYmZvby5zbyBm aXJzdCAtLSBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSAvdXNyL2xpYiBpcyBodWdlLg0KICAq IFdoZW4gZG9pbmcgKGxvYWQtZm9yZWlnbi1saWJyYXJ5ICIvZ251L3N0b3JlLy4uLi9saWJm b28uc28iKQ0KICAgIChhYnNvbHV0ZSBmaWxlIG5hbWUhKSwgd291bGQgaXQgc2VhcmNoIGZv cg0KICAgIC9nbnUvc3RvcmUvLi4uL2xpYmZvby5zby5OP8KgIElmIHNvLCB0aGF0IHdvdWxk IGJlIHN1cnByaXNpbmcsDQogICAgZXNwZWNpYWxseSBpZiBsaWJmb28uc28uTiBleGlzdHMu DQogICogSWYgZG9pbmcgbGliZm9vLnNvLk4sIHdpbGwgaXQgc2VhcmNoIGZvciBsaWJmb28u c28uTi5NPw0KICAqIERvZXMgaXQgb25seSBhcHBseSB0byB0aGUgc3lzdGVtIHBhdGhzLCBv ciBhbHNvIHRvDQogICAgR1VJTEVfU1lTVEVNX0VYVEVOU0lPTl9QQVRILCBMVERMX0xJQlJB UllfUEFUSCBhbmQNCiAgICBHVUlMRV9FWFRFTlNJT05fUEFUSD8gVGhlIGxhdHRlciB3b3Vs ZCBiZSBzdXJwcmlzaW5nIHRvIG1lLCBhcw0KICAgIHZlcnNpb25pbmcgaXMgbW9yZSBvZiBh IHN5c3RlbSB0aGluZy4NCiAgKiBUbyB0ZXN0IGl0LCBhbmQgYXZvaWQgYnJlYWtpbmcgdGhp bmdzIGxhdGVyIHdpdGggZnV0dXJlIGNoYW5nZXMgdG8NCiAgICBsb2FkLWZvcmVpZ24tbGli cmFyeSwgY291bGQgc29tZSB0ZXN0cyBiZSBhZGRlZD8NCiAgKiBJcyB0aGlzIGNoYW5nZSBk ZXNpcmFibGU/wqAgSSBtZWFuLCB0aGlzIGlzIGFuIEZGSSBBUEksIHNvIHRoZSBBQkkgb2YN CiAgICB0aGUgbGlicmFyeSBpcyByYXRoZXIgaW1wb3J0YW50LiBJZiBhIEd1aWxlIG1vZHVs ZSBsaW5rcyB0bw0KICAgIGxpYmZvby5zbywgYW5kIHRoZXkgaGFkIHZlcnNpb24gTiBpbiBt aW5kLCB0aGVuIGl0J3MgaW1wb3J0YW50IGl0DQogICAgZG9lc24ndCBsaW5rIHRvIE4tMSBv ciBOKzEgaW5zdGVhZCwgYmVjYXVzZSBvZiBBQkkNCiAgICBpbmNvbXBhdGliaWxpdGllcy4g QXMgc3VjaCwgdG8gbWUgaXQgc2VlbXMgX2dvb2RfIHRoYXQgeW91IGdvdCBzb21lDQogICAg ZXJyb3JzLCBhcyBub3cgeW91IGdldCBhIHJlbWluZGVyIHRvIGV4cGxpY2l0bHkgc3RhdGUg d2hpY2ggQUJJDQogICAgdmVyc2lvbiBpcyBuZWVkZWQuIChZTU1WLCBhbmQgdGhlIG1pbGVh Z2Ugb2YgdGhlIEd1aWxlIG1haW50YWluZXJzDQogICAgbWlnaHQgdmFyeSwgZXRjLikNCg0K QWxzbywgdGhpcyBzZWVtcyBsaWtlIGEgbm9uLXRyaXZpYWwgY2hhbmdlIHRvIG1lLCBzbyBh IGNvcHlyaWdodCBsaW5lIA0KbWlnaHQgYmUgaW4gb3JkZXIsIHVubGVzcyB5b3UgZGlkIHRo ZSBjb3B5cmlnaHQgYXNzaWdubWVudC4NCg0KR3JlZXRpbmdzLA0KTWF4aW1lLg0KDQo= --------------jVyWv6k2lftF6ZZEcSNY3zd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23-07-2022 13:09, soeren@soeren-tempel.net wrote:
From: S=C3=B6ren Tempel <soeren@soeren-tempel.net>

This patch is a fix for bug #49232 [1]. To summarize this bug, the
current load-foreign-library implementation does not load versioned
sonames (e.g. libfoo.so.5) which are common on Linux. This is an issue
for us at Alpine Linux since we ship unversioned sonames (e.g. libfoo.so)=

separately. Please refer to the original bug report for details.
 [...]

Long term, I think it would be ideal for Guile to decide upon a major version (and maybe even location, depending on the choices of the distro) at _compile_ time instead of runtime, not unlike how other compilers work.

More concretely, we could have a macro 'link-foreign-library', of the form:

(link-foreign-library library [maybe other arguments).

If the Guile module is being compiled with --rpath, it searches $CROSS_LIBRARY_PATH or $LIBRARY_PATH and encodes the full file name (/usr/lib/.../libguile-... or /gnu/store/.../lib/...) in the .go, which avoids some manual patching we have to do in Guix.

It could also detect if it's loading a libfoo.so pointing to libfoo.so.N, and if so, replace libfoo.so by libfoo.so.N.

The former (rpath) would work for Guix, and I expect the latter (libfoo.so -> libfoo.so.N) to work on Alpine.

+(define (file-exists-in-d=
ir-with-extension dir basename exts)
+  (let* ((dir-stream (opendir dir))
+         (ret (let loop ((fn (readdir dir-stream)))
+                (and (not (eof-object? fn))
+                     (if (filename-matches-with-extension? fn basename e=
xts)
+                       (in-vicinity dir fn)
+                       (loop (readdir dir-stream)))))))
IIUC, the string-prefix? search is non-deterministic, which can make debugging complicated when multiple versions are installed.=C2= =A0 I think it would be better to bail out if there are multiple matches instead of a risk of guessing incorrectly.

The prefixing behaviour is also not documented, so some documentation is needed in the manual.

Questions:

  • Does it go scanning the dir even if libfoo.so could be found?=C2= =A0 Otherwise, there are some possible performance gains by checking for libfoo.so first -- consider the case where /usr/lib is huge.<= br>
  • When doing (load-foreign-library "/gnu/store/.../libfoo.so") (absolute file name!), would it search for /gnu/store/.../libfoo.so.N?=C2=A0 If so, that would be surprising= , especially if libfoo.so.N exists.
  • If doing libfoo.so.N, will it search for libfoo.so.N.M?
  • Does it only apply to the system paths, or also to GUILE_SYSTEM_EXTENSION_PATH, LTDL_LIBRARY_PATH and GUILE_EXTENSION_PATH? The latter would be surprising to me, as versioning is more of a system thing.
  • To test it, and avoid breaking things later with future changes to load-foreign-library, could some tests be added?
  • Is this change desirable?=C2=A0 I mean, this is an FFI API, so = the ABI of the library is rather important. If a Guile module links to libfoo.so, and they had version N in mind, then it's important it doesn't link to N-1 or N+1 instead, because of ABI incompatibilities. As such, to me it seems _good_ that you got some errors, as now you get a reminder to explicitly state which ABI version is needed. (YMMV, and the mileage of the Guile maintainers might vary, etc.)

Also, this seems like a non-trivial change to me, so a copyright line might be in order, unless you did the copyright assignment.

Greetings,
Maxime.

--------------jVyWv6k2lftF6ZZEcSNY3zd7-- --------------E6Yf2tdnFB135m1JzBI6K4p3 Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------E6Yf2tdnFB135m1JzBI6K4p3-- --------------I6tQcbRO09NW77TqhkF0Hfwq-- --------------lzr087glQbV3cTXzmjKjGidU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYtv05AUDAAAAAAAKCRBJ4+4iGRcl7tXW AP92b9pfgKOJViKiM+iMAmMwz4S2i1zcDWPb/j+eYIK46AEA23pnhaWQ/++SAUwTQLQUC/Q/6EYh j440KD9xyZ9QQQg= =q3pP -----END PGP SIGNATURE----- --------------lzr087glQbV3cTXzmjKjGidU-- From unknown Sat Jun 14 03:57:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49232: [PATCH] load-foreign-library: perform substring match on library files Resent-From: soeren@soeren-tempel.net Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 23 Jul 2022 15:08:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49232 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: 49232@debbugs.gnu.org Cc: guile-devel@gnu.org X-Debbugs-Original-To: bug-guile@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.165858885628136 (code B ref -1); Sat, 23 Jul 2022 15:08:03 +0000 Received: (at submit) by debbugs.gnu.org; 23 Jul 2022 15:07:36 +0000 Received: from localhost ([127.0.0.1]:46039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFGj9-0007Jj-MK for submit@debbugs.gnu.org; Sat, 23 Jul 2022 11:07:36 -0400 Received: from lists.gnu.org ([209.51.188.17]:46352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFD1M-0002j5-K8 for submit@debbugs.gnu.org; Sat, 23 Jul 2022 07:10:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFD1M-0003AM-6U; Sat, 23 Jul 2022 07:10:08 -0400 Received: from magnesium.8pit.net ([45.76.88.171]:19212) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFD1J-00022N-MQ; Sat, 23 Jul 2022 07:10:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=opensmtpd; bh=BhkY6Xe2GU yM0zbrkEwred86gwWh9yHDxIvRixqPANM=; h=references:in-reply-to:date: subject:cc:to:from; d=soeren-tempel.net; b=nnazJ49FIfHh0dptAjOd9LTqTbJ qeB8vvXeLeNPx5PBqmexxH3iYmCPha7lMOC2h2SyUyhiXj0IXRlV/MrZes9ei71fBNvLsX 4mcWfIkbXsMlDFP6U2lmqzywl97EqNsBBKKJ3NhyW7NJaqH3v8RcEKX3vDEX0ijQ6ttAIh uG78= Received: from localhost (ipb218e485.dynamic.kabel-deutschland.de [178.24.228.133]) by magnesium.8pit.net (OpenSMTPD) with ESMTPSA id 54d12e93 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:YES); Sat, 23 Jul 2022 13:09:56 +0200 (CEST) From: soeren@soeren-tempel.net Date: Sat, 23 Jul 2022 13:09:20 +0200 Message-Id: <20220723110919.30107-1-soeren@soeren-tempel.net> X-Mailer: git-send-email 2.37.1 In-Reply-To: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=45.76.88.171; envelope-from=soeren@soeren-tempel.net; helo=magnesium.8pit.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Mailman-Approved-At: Sat, 23 Jul 2022 11:07:33 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) From: Sören Tempel This patch is a fix for bug #49232 [1]. To summarize this bug, the current load-foreign-library implementation does not load versioned sonames (e.g. libfoo.so.5) which are common on Linux. This is an issue for us at Alpine Linux since we ship unversioned sonames (e.g. libfoo.so) separately. Please refer to the original bug report for details. This patch attempts to fix this issue by performing a substring match on library files in load-foreign-library. That is, when loading the library file for `libfoo` the new algorithm will perform a substring prefix match and return the first file which starts with `libfoo.so`. Therefore, the new algorithm will match both `libfoo.so.5` and `libfoo.so` while the current algorithm only matched the latter. In order to implement this, the new algorithm has to perform a readdir(2) syscall on directories in $LD_LIBRARY_PATH instead of just checking for the presence of a single file in each directory. Discussion: It may be desirable to make the prefix substring check more strict, presently `libzstd.something` would also match. While I believe it to be unlikely that such files exist in $LD_LIBRARY_PATH we could also perform a substring match against `basename + ext + #\.`, i.e. libzstd.so., libstzstd.so.1, libzstd.so.1.5.2 etc would match but libzstd.something wouldn't. Furthermore, if both libzstd.so.1 and libzstd.so exist in $LD_LIBRARY_PATH then the algorithm proposed here may prefer the former (depending on the readdir(2) file order). * module/system/foreign-library.scm (file-exists-in-path-with-extension): perform a substring match on library files to also match versioned .so files. * modules/system/foreign-library.scm (load-foreign-library): Perform a fuzzy substring search even if the library file contains a path-separator. [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49232 Signed-off-by: Sören Tempel --- This is my first patch for guile, if I missed anything please let me know. Also, I am not subscribed to the list so please CC me. module/system/foreign-library.scm | 63 +++++++++++++++++-------------- 1 file changed, 34 insertions(+), 29 deletions(-) diff --git a/module/system/foreign-library.scm b/module/system/foreign-library.scm index dc426385f..87e5a3afc 100644 --- a/module/system/foreign-library.scm +++ b/module/system/foreign-library.scm @@ -57,30 +57,33 @@ (else '(".so")))) -(define (has-extension? head exts) - (match exts - (() #f) - ((ext . exts) - (or (string-contains head ext) - (has-extension? head exts))))) - -(define (file-exists-with-extension head exts) - (if (has-extension? head exts) - (and (file-exists? head) head) - (let lp ((exts exts)) - (match exts - (() #f) - ((ext . exts) - (let ((head (string-append head ext))) - (if (file-exists? head) - head - (lp exts)))))))) +(define (filename-matches-with-extension? filename basename exts) + (let lp ((exts exts)) + (match exts + (() #f) + ((ext . exts) + ;; Fuzzy comparison of filename with basename + ext. If the + ;; latter is a prefix of the former, consider it a match. This + ;; allows matching .so files with versions, e.g. libfoo.so.5. + (let ((prefix (string-append basename ext))) + (or (string-prefix? prefix filename) + (lp exts))))))) + +(define (file-exists-in-dir-with-extension dir basename exts) + (let* ((dir-stream (opendir dir)) + (ret (let loop ((fn (readdir dir-stream))) + (and (not (eof-object? fn)) + (if (filename-matches-with-extension? fn basename exts) + (in-vicinity dir fn) + (loop (readdir dir-stream))))))) + (closedir dir-stream) + ret)) (define (file-exists-in-path-with-extension basename path exts) (match path (() #f) ((dir . path) - (or (file-exists-with-extension (in-vicinity dir basename) exts) + (or (file-exists-in-dir-with-extension dir basename exts) (file-exists-in-path-with-extension basename path exts))))) (define path-separator @@ -198,16 +201,18 @@ name." (dlopen* #f)) ((or (absolute-file-name? filename) (string-any file-name-separator? filename)) - (cond - ((or (file-exists-with-extension filename extensions) - (and search-ltdl-library-path? - (file-exists-with-extension - (in-vicinity (in-vicinity (dirname filename) ".libs") - (basename filename)) - extensions))) - => dlopen*) - (else - (error-not-found)))) + (let ((dirname (dirname filename)) + (basename (basename filename))) + (cond + ((or (file-exists-in-dir-with-extension dirname basename extensions) + (and search-ltdl-library-path? + (file-exists-in-dir-with-extension + (in-vicinity dirname ".libs") + basename + extensions))) + => dlopen*) + (else + (error-not-found))))) ((file-exists-in-path-with-extension filename search-path extensions) => dlopen*) (search-system-paths? From unknown Sat Jun 14 03:57:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49232: [PATCH] load-foreign-library: perform substring match on library files Resent-From: =?UTF-8?Q?S=C3=B6ren?= Tempel Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 24 Jul 2022 12:34:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49232 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: Maxime Devos Cc: 49232@debbugs.gnu.org, guile-devel@gnu.org X-Debbugs-Original-Cc: bug-guile@gnu.org, guile-devel@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.165866602713504 (code B ref -1); Sun, 24 Jul 2022 12:34:03 +0000 Received: (at submit) by debbugs.gnu.org; 24 Jul 2022 12:33:47 +0000 Received: from localhost ([127.0.0.1]:47045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFanp-0003Vb-QX for submit@debbugs.gnu.org; Sun, 24 Jul 2022 08:33:47 -0400 Received: from lists.gnu.org ([209.51.188.17]:37246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFaXI-0002zT-TV for submit@debbugs.gnu.org; Sun, 24 Jul 2022 08:16:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFaXI-00022b-Ig; Sun, 24 Jul 2022 08:16:40 -0400 Received: from magnesium.8pit.net ([45.76.88.171]:8213) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFaXF-0007Fs-Ro; Sun, 24 Jul 2022 08:16:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=opensmtpd; bh=h7qK54DA36 y71eN1MQQuKsXvDhM1TBozg+jaCvi95zY=; h=in-reply-to:references:from: subject:cc:to:date; d=soeren-tempel.net; b=JNKU7oNr14IHj5a98X7/vG2pnuU B1AdO8uBn9vqGtSxenzHwCMXkuIRB6XpFOce1pRVU7mtntrEagXfyJQ+LBbMMyqA0B6AOe 7NGROFfxjj/H6j47mhpO8ywzulG0UQ2mvy20YudrIWHfk5saYFo59+wMsxprt3m++ar6XK jNZw= Received: from localhost (p200300f5ff05aa00efb8aa09824b98d4.dip0.t-ipconnect.de [2003:f5:ff05:aa00:efb8:aa09:824b:98d4]) by magnesium.8pit.net (OpenSMTPD) with ESMTPSA id 605b84b6 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:YES); Sun, 24 Jul 2022 14:16:30 +0200 (CEST) Date: Sun, 24 Jul 2022 14:16:25 +0200 From: =?UTF-8?Q?S=C3=B6ren?= Tempel References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> <20220723110919.30107-1-soeren@soeren-tempel.net> <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be> In-Reply-To: <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be> Message-Id: <2EA1MELO27342.28JGAL8QO05T4@8pit.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=45.76.88.171; envelope-from=soeren@soeren-tempel.net; helo=magnesium.8pit.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Mailman-Approved-At: Sun, 24 Jul 2022 08:33:39 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hi, Thanks for your feedback, comments below. Maxime Devos wrote: > Long term, I think it would be ideal for Guile to decide upon a major=20 > version (and maybe even location, depending on the choices of the=20 > distro) at _compile_ time instead of runtime, not unlike how other=20 > compilers work. Sure, that could work too. > If the Guile module is being compiled with --rpath, it searches > $CROSS_LIBRARY_PATH or $LIBRARY_PATH and encodes the full file name > (/usr/lib/.../libguile-... or /gnu/store/.../lib/...) in the .go, > which avoids some manual patching we have to do in Guix. What kind of manual patching do you do on Guix? Could you refer me to the code for that? Maybe that's something we could also do on Alpine in the meantime. > IIUC, the string-prefix? search is non-deterministic, which can make=20 > debugging complicated when multiple versions are installed.=20 Well, on Linux readdir(3) file name order depends on the file system implementation. Since the algorithm returns the first file with a substring match, it depends on the readdir order. As long as the same filesystem is used, it should be deterministic. > I think it would be better to bail out if there are multiple matches > instead of a risk of guessing incorrectly. Many packages provide multiple .so files with different version granularity so bailing out if there are multiple substring matches doesn't really work. For example, for libgit2 I have the following files installed on my system: $ ls /usr/lib/libgit2* /usr/lib/libgit2.so.1.4 /usr/lib/libgit2.so.1.4.4 Where the former is a symlink to the latter. However, it would be possible to collect all substring matches and prioritize them according to some algorithm (e.g. alphabetical order). This would also make the algorithm independent of the readdir(3) order. > The prefixing behaviour is also not documented, so some documentation is=20= > needed in the manual. I can add some documentation if there is interest in merging this. > * Does it go scanning the dir even if libfoo.so could be found? > Otherwise, there are some possible performance gains by checking for > libfoo.so first -- consider the case where /usr/lib is huge. Yes, a fast path could be added though you probably really need to have a lot of files installed in /usr/lib for this to be worth it. > * When doing (load-foreign-library "/gnu/store/.../libfoo.so") > (absolute file name!), would it search for > /gnu/store/.../libfoo.so.N?=C2=A0 If so, that would be surprising, > especially if libfoo.so.N exists. Yep, it does. I originally didn't want to modify the handling of absolute paths but unfortunately during testing I noticed that Guile extensions seem to be loaded with an absolute path and hence don't work without the libfoo.so symlink [1]. > * If doing libfoo.so.N, will it search for libfoo.so.N.M? Yes, since libfoo.so.N is a prefix of libfoo.so.N.M. > * Does it only apply to the system paths, or also to > GUILE_SYSTEM_EXTENSION_PATH, LTDL_LIBRARY_PATH and > GUILE_EXTENSION_PATH? The latter would be surprising to me, as > versioning is more of a system thing. If those paths are also searched using the load-foreign-library procedure then they are affected by this change. Also, I am not a Guile expert but on Alpine, Guile extensions such as guile-reader also ship versioned sonames [1]. > * To test it, and avoid breaking things later with future changes to > load-foreign-library, could some tests be added? Probably, though I am not familiar with the Guile test setup and there don't seem to be any existing tests for foreign-library. > * Is this change desirable?=C2=A0 I mean, this is an FFI API, so the ABI= of > the library is rather important. If a Guile module links to > libfoo.so, and they had version N in mind, then it's important it > doesn't link to N-1 or N+1 instead, because of ABI > incompatibilities. As such, to me it seems _good_ that you got some > errors, as now you get a reminder to explicitly state which ABI > version is needed. (YMMV, and the mileage of the Guile maintainers > might vary, etc.) In my experience, most languages which don't link against shared libraries directly but instead load them at run-time don't hardcode ABI versions (for example, refer to Python's ctypes.util.find_library). Also, the current implementation of load-foreign-library does not force you to specify an ABI version but instead loads whatever the libfoo.so symlink refers to. > Also, this seems like a non-trivial change to me, so a copyright line=20 > might be in order, unless you did the copyright assignment. I didn't do any copyright assignment yet but if there is actually any interest in merging this then I can do it once we agreed on changes to the algorithm. Greetings, S=C3=B6ren [1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12783 From unknown Sat Jun 14 03:57:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49232: [PATCH] load-foreign-library: perform substring match on library files Resent-From: =?UTF-8?Q?S=C3=B6ren?= Tempel Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 20 Aug 2022 17:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49232 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: Maxime Devos Cc: 49232@debbugs.gnu.org, guile-devel@gnu.org X-Debbugs-Original-Cc: bug-guile@gnu.org, guile-devel@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166101830525404 (code B ref -1); Sat, 20 Aug 2022 17:59:01 +0000 Received: (at submit) by debbugs.gnu.org; 20 Aug 2022 17:58:25 +0000 Received: from localhost ([127.0.0.1]:33478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPSjn-0006be-GM for submit@debbugs.gnu.org; Sat, 20 Aug 2022 13:58:25 -0400 Received: from lists.gnu.org ([209.51.188.17]:38282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPOtv-0000AQ-Do for submit@debbugs.gnu.org; Sat, 20 Aug 2022 09:52:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50988) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPOtv-0004f9-3t; Sat, 20 Aug 2022 09:52:35 -0400 Received: from magnesium.8pit.net ([45.76.88.171]:11975) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPOts-0000gL-Nr; Sat, 20 Aug 2022 09:52:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=opensmtpd; bh=ehwSRmQn4l FQch+fdYUA2OVsCkvh7NAsTGC4cwSfwaw=; h=in-reply-to:references:from: subject:cc:to:date; d=soeren-tempel.net; b=nj7o8GVCuQPv+/vHhZtSy2zuOhm MNhS1ezo5s9v5yA5xoXEFY2ZnVSVYYKZhipGK9/tioCdDxM5KYPgCP/xVlszs1cVOxj0q4 wV5NDkLmE2pW/yCLlz/NWs6A5DNtLa7Hz5Wceam9j7KF64NkZfnIpSWH7Sm0I5zHh3sDZa kze4= Received: from localhost (p200300f5ff05aa009d746ddc22c1eda1.dip0.t-ipconnect.de [2003:f5:ff05:aa00:9d74:6ddc:22c1:eda1]) by magnesium.8pit.net (OpenSMTPD) with ESMTPSA id 6cc17e7f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:YES); Sat, 20 Aug 2022 15:52:24 +0200 (CEST) Date: Sat, 20 Aug 2022 15:52:21 +0200 From: =?UTF-8?Q?S=C3=B6ren?= Tempel References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> <20220723110919.30107-1-soeren@soeren-tempel.net> <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be> <2EA1MELO27342.28JGAL8QO05T4@8pit.net> In-Reply-To: <2EA1MELO27342.28JGAL8QO05T4@8pit.net> Message-Id: <27GGIELIPN05K.2DRSYZVI36WYY@8pit.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=45.76.88.171; envelope-from=soeren@soeren-tempel.net; helo=magnesium.8pit.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Mailman-Approved-At: Sat, 20 Aug 2022 13:58:22 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hi, How do we proceed with this? I would especially be interested in the "patching" that you do in Guix. Maybe that would also be a suitable workaround for us on the Alpine side until this is sorted out properly. Greetings, S=C3=B6ren S=C3=B6ren Tempel wrote: > Hi, >=20 > Thanks for your feedback, comments below. >=20 > Maxime Devos wrote: > > Long term, I think it would be ideal for Guile to decide upon a major=20= > > version (and maybe even location, depending on the choices of the=20 > > distro) at _compile_ time instead of runtime, not unlike how other=20 > > compilers work. >=20 > Sure, that could work too. >=20 > > If the Guile module is being compiled with --rpath, it searches > > $CROSS_LIBRARY_PATH or $LIBRARY_PATH and encodes the full file name > > (/usr/lib/.../libguile-... or /gnu/store/.../lib/...) in the .go, > > which avoids some manual patching we have to do in Guix. >=20 > What kind of manual patching do you do on Guix? Could you refer me to > the code for that? Maybe that's something we could also do on Alpine in > the meantime. >=20 > > IIUC, the string-prefix? search is non-deterministic, which can make=20= > > debugging complicated when multiple versions are installed.=20 >=20 > Well, on Linux readdir(3) file name order depends on the file system > implementation. Since the algorithm returns the first file with a > substring match, it depends on the readdir order. As long as the same > filesystem is used, it should be deterministic. >=20 > > I think it would be better to bail out if there are multiple matches > > instead of a risk of guessing incorrectly. >=20 > Many packages provide multiple .so files with different version > granularity so bailing out if there are multiple substring matches > doesn't really work. For example, for libgit2 I have the following files > installed on my system: >=20 > $ ls /usr/lib/libgit2* > /usr/lib/libgit2.so.1.4 > /usr/lib/libgit2.so.1.4.4 >=20 > Where the former is a symlink to the latter. However, it would be > possible to collect all substring matches and prioritize them according > to some algorithm (e.g. alphabetical order). This would also make the > algorithm independent of the readdir(3) order. >=20 > > The prefixing behaviour is also not documented, so some documentation i= s=20 > > needed in the manual. >=20 > I can add some documentation if there is interest in merging this. >=20 > > * Does it go scanning the dir even if libfoo.so could be found? > > Otherwise, there are some possible performance gains by checking fo= r > > libfoo.so first -- consider the case where /usr/lib is huge. >=20 > Yes, a fast path could be added though you probably really need to have > a lot of files installed in /usr/lib for this to be worth it. >=20 > > * When doing (load-foreign-library "/gnu/store/.../libfoo.so") > > (absolute file name!), would it search for > > /gnu/store/.../libfoo.so.N?=C2=A0 If so, that would be surprising, > > especially if libfoo.so.N exists. >=20 > Yep, it does. I originally didn't want to modify the handling of > absolute paths but unfortunately during testing I noticed that Guile > extensions seem to be loaded with an absolute path and hence don't > work without the libfoo.so symlink [1]. >=20 > > * If doing libfoo.so.N, will it search for libfoo.so.N.M? >=20 > Yes, since libfoo.so.N is a prefix of libfoo.so.N.M. >=20 > > * Does it only apply to the system paths, or also to > > GUILE_SYSTEM_EXTENSION_PATH, LTDL_LIBRARY_PATH and > > GUILE_EXTENSION_PATH? The latter would be surprising to me, as > > versioning is more of a system thing. >=20 > If those paths are also searched using the load-foreign-library > procedure then they are affected by this change. Also, I am not a Guile > expert but on Alpine, Guile extensions such as guile-reader also ship > versioned sonames [1]. >=20 > > * To test it, and avoid breaking things later with future changes to > > load-foreign-library, could some tests be added? >=20 > Probably, though I am not familiar with the Guile test setup and there > don't seem to be any existing tests for foreign-library. >=20 > > * Is this change desirable?=C2=A0 I mean, this is an FFI API, so the A= BI of > > the library is rather important. If a Guile module links to > > libfoo.so, and they had version N in mind, then it's important it > > doesn't link to N-1 or N+1 instead, because of ABI > > incompatibilities. As such, to me it seems _good_ that you got some > > errors, as now you get a reminder to explicitly state which ABI > > version is needed. (YMMV, and the mileage of the Guile maintainers > > might vary, etc.) >=20 > In my experience, most languages which don't link against shared > libraries directly but instead load them at run-time don't hardcode ABI > versions (for example, refer to Python's ctypes.util.find_library). > Also, the current implementation of load-foreign-library does not force > you to specify an ABI version but instead loads whatever the libfoo.so > symlink refers to. >=20 > > Also, this seems like a non-trivial change to me, so a copyright line=20= > > might be in order, unless you did the copyright assignment. >=20 > I didn't do any copyright assignment yet but if there is actually any > interest in merging this then I can do it once we agreed on changes to > the algorithm. >=20 > Greetings, > S=C3=B6ren >=20 > [1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12783 From unknown Sat Jun 14 03:57:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49232: [PATCH] load-foreign-library: perform substring match on library files Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 20 Aug 2022 18:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49232 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: =?UTF-8?Q?S=C3=B6ren?= Tempel Cc: 49232@debbugs.gnu.org, guile-devel@gnu.org X-Debbugs-Original-Cc: bug-guile@gnu.org, guile-devel@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166102022028539 (code B ref -1); Sat, 20 Aug 2022 18:31:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 Aug 2022 18:30:20 +0000 Received: from localhost ([127.0.0.1]:33505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPTEh-0007QE-Sp for submit@debbugs.gnu.org; Sat, 20 Aug 2022 14:30:20 -0400 Received: from lists.gnu.org ([209.51.188.17]:39700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPTEd-0007Q4-9o for submit@debbugs.gnu.org; Sat, 20 Aug 2022 14:30:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPTEd-0008AH-0x for bug-guile@gnu.org; Sat, 20 Aug 2022 14:30:15 -0400 Received: from michel.telenet-ops.be ([2a02:1800:110:4::f00:18]:46288) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oPTEX-0002el-Rf for bug-guile@gnu.org; Sat, 20 Aug 2022 14:30:14 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by michel.telenet-ops.be with bizsmtp id 9uW32800D20ykKC06uW3MF; Sat, 20 Aug 2022 20:30:03 +0200 Message-ID: <8c61d7cd-553a-6e48-53b6-3563acba253d@telenet.be> Date: Sat, 20 Aug 2022 20:30:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> <20220723110919.30107-1-soeren@soeren-tempel.net> <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be> <2EA1MELO27342.28JGAL8QO05T4@8pit.net> From: Maxime Devos In-Reply-To: <2EA1MELO27342.28JGAL8QO05T4@8pit.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------hRYIOB5x8etmL3n1jK5Hv5bo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1661020203; bh=cq9+6F6u4gsv64qeL+eBu77Z8cdnZbuPMSUuSPE1vtQ=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=C2WLfbWBelNkCWzkbO5pDJo71N9Nbkm51Q1WwXqY7omtTiwuvpNk+/VX48yvO0AMG qJBX5+3dJ5YbL4+s9fBPIwiSb6vNvK5YWacAgX9YTv13ZywiDIjAwHnqTNmFhK8L/J UZ/Ii7GLJdQVohYMcnxfkFmzKEW6ZeL5SwP6tp5QdBUZhTJMBjEcIMyyZko5de9B6Q USpHgA4s93k/AXPOBPhuPyPM3K6zwn+Q9ftB/c4ILbbCWHVoOHwYi5jYSXgg5cnE/7 wxsbetc4bD68unRE1j86iVLinBBG/TUOUzZsgNzTnAj1qYv+WIae9euOgw3HpUJ7YW f96BM/agFFT9g== Received-SPF: pass client-ip=2a02:1800:110:4::f00:18; envelope-from=maximedevos@telenet.be; helo=michel.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hRYIOB5x8etmL3n1jK5Hv5bo Content-Type: multipart/mixed; boundary="------------c11BUmnRC3DcQe0RBR0rIUIW"; protected-headers="v1" From: Maxime Devos To: =?UTF-8?Q?S=c3=b6ren_Tempel?= Cc: bug-guile@gnu.org, guile-devel@gnu.org Message-ID: <8c61d7cd-553a-6e48-53b6-3563acba253d@telenet.be> Subject: Re: [PATCH] load-foreign-library: perform substring match on library files References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> <20220723110919.30107-1-soeren@soeren-tempel.net> <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be> <2EA1MELO27342.28JGAL8QO05T4@8pit.net> In-Reply-To: <2EA1MELO27342.28JGAL8QO05T4@8pit.net> --------------c11BUmnRC3DcQe0RBR0rIUIW Content-Type: multipart/mixed; boundary="------------0SdRp0NCFPS8AY0fP1W0V0bE" --------------0SdRp0NCFPS8AY0fP1W0V0bE Content-Type: multipart/alternative; boundary="------------7TKEkSgR5EaWS4SKEfwdUj0K" --------------7TKEkSgR5EaWS4SKEfwdUj0K Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAyNC0wNy0yMDIyIDE0OjE2LCBTw7ZyZW4gVGVtcGVsIHdyb3RlOg0KPiBIaSwNCj4N Cj4gVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLCBjb21tZW50cyBiZWxvdy4NCj4NCj4gTWF4 aW1lIERldm9zPG1heGltZWRldm9zQHRlbGVuZXQuYmU+ICB3cm90ZToNCj4+IExvbmcgdGVy bSwgSSB0aGluayBpdCB3b3VsZCBiZSBpZGVhbCBmb3IgR3VpbGUgdG8gZGVjaWRlIHVwb24g YSBtYWpvcg0KPj4gdmVyc2lvbiAoYW5kIG1heWJlIGV2ZW4gbG9jYXRpb24sIGRlcGVuZGlu ZyBvbiB0aGUgY2hvaWNlcyBvZiB0aGUNCj4+IGRpc3RybykgYXQgX2NvbXBpbGVfIHRpbWUg aW5zdGVhZCBvZiBydW50aW1lLCBub3QgdW5saWtlIGhvdyBvdGhlcg0KPj4gY29tcGlsZXJz IHdvcmsuDQo+IFN1cmUsIHRoYXQgY291bGQgd29yayB0b28uDQo+DQo+PiBJZiB0aGUgR3Vp bGUgbW9kdWxlIGlzIGJlaW5nIGNvbXBpbGVkIHdpdGggLS1ycGF0aCwgaXQgc2VhcmNoZXMN Cj4+ICRDUk9TU19MSUJSQVJZX1BBVEggb3IgJExJQlJBUllfUEFUSCBhbmQgZW5jb2RlcyB0 aGUgZnVsbCBmaWxlIG5hbWUNCj4+ICgvdXNyL2xpYi8uLi4vbGliZ3VpbGUtLi4uIG9yIC9n bnUvc3RvcmUvLi4uL2xpYi8uLi4pIGluIHRoZSAuZ28sDQo+PiB3aGljaCBhdm9pZHMgc29t ZSBtYW51YWwgcGF0Y2hpbmcgd2UgaGF2ZSB0byBkbyBpbiBHdWl4Lg0KPiBXaGF0IGtpbmQg b2YgbWFudWFsIHBhdGNoaW5nIGRvIHlvdSBkbyBvbiBHdWl4PyBDb3VsZCB5b3UgcmVmZXIg bWUgdG8NCj4gdGhlIGNvZGUgZm9yIHRoYXQ/IE1heWJlIHRoYXQncyBzb21ldGhpbmcgd2Ug Y291bGQgYWxzbyBkbyBvbiBBbHBpbmUgaW4NCj4gdGhlIG1lYW50aW1lLg0KDQpBIGZldyBl eGFtcGxlczoNCg0KICAqIGd1aWxlLWctZ29sZjoNCiAgICBodHRwczovL2dpdC5zYXZhbm5h aC5nbnUub3JnL2NnaXQvZ3VpeC5naXQvdHJlZS9nbnUvcGFja2FnZXMvZ3VpbGUteHl6LnNj bSNuMjAwNg0KICAqIGd1aWxlLWFydGFuaXM6DQogICAgaHR0cHM6Ly9naXQuc2F2YW5uYWgu Z251Lm9yZy9jZ2l0L2d1aXguZ2l0L3RyZWUvZ251L3BhY2thZ2VzL2d1aWxlLXh5ei5zY20j bjEzOQ0KICAqIGd1aWxlLWFzcGVsbDoNCiAgICBodHRwczovL2dpdC5zYXZhbm5haC5nbnUu b3JnL2NnaXQvZ3VpeC5naXQvdHJlZS9nbnUvcGFja2FnZXMvZ3VpbGUteHl6LnNjbSNuMzk1 DQogICogZ3VpbGUtc3F1ZXVlDQogICAgaHR0cHM6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9j Z2l0L2d1aXguZ2l0L3RyZWUvZ251L3BhY2thZ2VzL2d1aWxlLXh5ei5zY20jbjg3MA0KDQon Z3VpbGUtc3F1ZXVlJyBpcyBvbmUgb2YgdGhlIHNpbXBsZXN0IGV4YW1wbGVzLg0KDQo+PiBJ SVVDLCB0aGUgc3RyaW5nLXByZWZpeD8gc2VhcmNoIGlzIG5vbi1kZXRlcm1pbmlzdGljLCB3 aGljaCBjYW4gbWFrZQ0KPj4gZGVidWdnaW5nIGNvbXBsaWNhdGVkIHdoZW4gbXVsdGlwbGUg dmVyc2lvbnMgYXJlIGluc3RhbGxlZC4NCj4gV2VsbCwgb24gTGludXggcmVhZGRpcigzKSBm aWxlIG5hbWUgb3JkZXIgZGVwZW5kcyBvbiB0aGUgZmlsZSBzeXN0ZW0NCj4gaW1wbGVtZW50 YXRpb24uIFNpbmNlIHRoZSBhbGdvcml0aG0gcmV0dXJucyB0aGUgZmlyc3QgZmlsZSB3aXRo IGENCj4gc3Vic3RyaW5nIG1hdGNoLCBpdCBkZXBlbmRzIG9uIHRoZSByZWFkZGlyIG9yZGVy LiBBcyBsb25nIGFzIHRoZSBzYW1lDQo+IGZpbGVzeXN0ZW0gaXMgdXNlZCwgaXQgc2hvdWxk IGJlIGRldGVybWluaXN0aWMuDQoNCidGaWxlIHN5c3RlbS1zcGVjaWZpYycgaXMgYSBmb3Jt IG9mIG5vbi1kZXRlcm1pbmlzbS4gQWRkaXRpb25hbGx5LCB0aGUgDQpmaWxlIHN5c3RlbSBp bXBsZW1lbnRhdGlvbiBjYW4gY2hhbmdlIG92ZXIgdGltZSwgc28gZXZlbiBpZiBhIGZpbGUg DQpzeXN0ZW0gaXMgZml4ZWQgaW4gYWR2YW5jZSwgaXQgd291bGQgc3RpbGwgYmUgbm9uLWRl dGVybWluaXN0aWMuDQoNCkV2ZW4gaWYgdGhlIGZpbGUgc3lzdGVtIGltcGxlbWVudGF0aW9u IGRvZXNuJ3QgY2hhbmdlLCB0aGVyZSBjYW4gc3RpbGwgDQpiZSBub24tZGV0ZXJtaW5pc20u IEZvciBleGFtcGxlLCBpZiBkaXJlY3RvcmllcyBhcmUgaW1wbGVtZW50ZWQgYXMgaGFzaCAN CnRhYmxlcyBhbmQgJ3JlYWRkaXInIGl0ZXJhdGVzIG92ZXIgdGhlIGJ1Y2tldHMgLS0gaWYg b3RoZXIgZmlsZXMgYXJlIA0KYWRkZWQgb3IgcmVtb3ZlZCwgdGhlIHNpemUgY2hhbmdlcywg d2hpY2ggY2FuIGNhdXNlIGRpZmZlcmVudCBoYXNoZWQgdG8gDQpiZSB1c2VkIGFuZCBoZW5j ZSBhIGRpZmZlcmVudCBvcmRlci4gQXMgc3VjaCwgdGhlIHJlYWRkaXIgb3JkZXIgY2FuIA0K ZGVwZW5kIG9uIHRoZSBwcmVzZW5jZSBhbmQgYWJzZW5jZSBvZiBvdGhlciBmaWxlcywgd2hp Y2ggc2VlbXMgYW4gDQp1bmRlc2lyYWJsZSBmb3JtIG9mIG5vbi1kZXRlcm1pbmlzbSB0byBt ZS4NCg0KPj4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYmFpbCBvdXQgaWYgdGhl cmUgYXJlIG11bHRpcGxlIG1hdGNoZXMNCj4+IGluc3RlYWQgb2YgYSByaXNrIG9mIGd1ZXNz aW5nIGluY29ycmVjdGx5Lg0KDQpJbiB0aGF0IHNpdHVhdGlvbiwgdGhleSBhcmUgYWxsIHRo ZSBzYW1lIGZpbGUsIGp1c3Qgd2l0aCBhIGRpZmZlcmVudCANCm5hbWUsIHNvIGluIHRoYXQg c2l0dWF0aW9uIGl0J3Mgbm8gcHJvYmxlbS4NCg0KSG93ZXZlciwgY29uc2lkZXIgbXVsdGlw bGUgKHBvdGVudGlhbGx5IGluY29tcGF0aWJsZSkgdmVyc2lvbnMuIFdoYXQgDQp2ZXJzaW9u IGRvIHlvdSBzZWxlY3QgdGhlbj8gTWF5YmUganVzdCB0aGUgbGF0ZXN0PyBCdXQgdGhleSBt aWdodCBiZSANCmluY29tcGF0aWJsZSAuLi4NCg0KPj4gICAgKiBXaGVuIGRvaW5nIChsb2Fk LWZvcmVpZ24tbGlicmFyeSAiL2dudS9zdG9yZS8uLi4vbGliZm9vLnNvIikNCj4+ICAgICAg KGFic29sdXRlIGZpbGUgbmFtZSEpLCB3b3VsZCBpdCBzZWFyY2ggZm9yDQo+PiAgICAgIC9n bnUvc3RvcmUvLi4uL2xpYmZvby5zby5OP8KgIElmIHNvLCB0aGF0IHdvdWxkIGJlIHN1cnBy aXNpbmcsDQo+PiAgICAgIGVzcGVjaWFsbHkgaWYgbGliZm9vLnNvLk4gZXhpc3RzLg0KPiBZ ZXAsIGl0IGRvZXMuIEkgb3JpZ2luYWxseSBkaWRuJ3Qgd2FudCB0byBtb2RpZnkgdGhlIGhh bmRsaW5nIG9mDQo+IGFic29sdXRlIHBhdGhzIGJ1dCB1bmZvcnR1bmF0ZWx5IGR1cmluZyB0 ZXN0aW5nIEkgbm90aWNlZCB0aGF0IEd1aWxlDQo+IGV4dGVuc2lvbnMgc2VlbSB0byBiZSBs b2FkZWQgd2l0aCBhbiBhYnNvbHV0ZSBwYXRoDQoNCkkgZG9uJ3Qgc2VlIHdoYXQncyB1bmZv cnR1bmF0ZSBhYm91dCB0aGF0Lg0KDQo+IGFuZCBoZW5jZSBkb24ndCB3b3JrIHdpdGhvdXQg dGhlIGxpYmZvby5zbyBzeW1saW5rIFsxXS4NCg0KU2VlbXMgdG8gd29yayBsb2NhbGx5Og0K DQoobG9hZC1leHRlbnNpb24gIi9ob21lL2FudGlwb2RlLy5ndWl4LWhvbWUvcHJvZmlsZS9s aWIvbGlicG5nMTYuc28uMTYiIA0KInQiKSA7IEluIHByb2NlZHVyZSBkbHN5bTogRXJyb3I6 IC4uLiAtLS0gdGhvdWdoIGxpYnJhcnkgd2FzIGxvYWRlZCANCnN1Y2Nlc2Z1bGx5Lg0KDQpJ dCBhcHBlYXJzIHRoYXQgbG9hZC1leHRlbnNpb24gYWxyZWFkeSBhdXRvbWF0aWNhbGx5IGFk ZHMgYSAuc28gdGhvdWdoIA0KKHRlc3RlZCB3aXRoIChsb2FkLWV4dGVuc2lvbiANCiIvaG9t ZS9hbnRpcG9kZS8uZ3VpeC1ob21lL3Byb2ZpbGUvbGliL2xpYnBuZzE2IiAidCIpLCBzbyBl eHRlbmRpbmcgaXQgDQp0byBhbHNvIGFkZCB0aGUgLk4gYXMgZG9uZSBoZXJlIGRvZXNuJ3Qg c2VlbSBhIHJlZ3Jlc3Npb24gdG8gbWUuDQoNCj4+ICAgICogSWYgZG9pbmcgbGliZm9vLnNv Lk4sIHdpbGwgaXQgc2VhcmNoIGZvciBsaWJmb28uc28uTi5NPw0KPiBZZXMsIHNpbmNlIGxp YmZvby5zby5OIGlzIGEgcHJlZml4IG9mIGxpYmZvby5zby5OLk0uDQoNCldoYXQgYWJvdXQ6 IOKAmElmIGRvaW5nIGxpYmZvby5zby41LCB3aWxsIGl0IGFjY2VwdCBsaWJmb28uc28uNTAi PyANCmxpYmZvby5zby41IGlzIGEgcHJlZml4IG9mIGxpYmZvby5zby41MCwgc28gdW5sZXNz IGNhcmUgaXMgdGFrZW4gd2l0aCANCmRvdHMsIGl0IGNvdWxkIGFjY2VwdCBhIGRpZmZlcmVu dCB2ZXJzaW9uIHRoYW4gd2FzIGFza2VkIGZvci4NCg0KPj4gICAgKiBEb2VzIGl0IG9ubHkg YXBwbHkgdG8gdGhlIHN5c3RlbSBwYXRocywgb3IgYWxzbyB0bw0KPj4gICAgICBHVUlMRV9T WVNURU1fRVhURU5TSU9OX1BBVEgsIExURExfTElCUkFSWV9QQVRIIGFuZA0KPj4gICAgICBH VUlMRV9FWFRFTlNJT05fUEFUSD8gVGhlIGxhdHRlciB3b3VsZCBiZSBzdXJwcmlzaW5nIHRv IG1lLCBhcw0KPj4gICAgICB2ZXJzaW9uaW5nIGlzIG1vcmUgb2YgYSBzeXN0ZW0gdGhpbmcu DQo+IElmIHRob3NlIHBhdGhzIGFyZSBhbHNvIHNlYXJjaGVkIHVzaW5nIHRoZSBsb2FkLWZv cmVpZ24tbGlicmFyeQ0KPiBwcm9jZWR1cmUgdGhlbiB0aGV5IGFyZSBhZmZlY3RlZCBieSB0 aGlzIGNoYW5nZS4gQWxzbywgSSBhbSBub3QgYSBHdWlsZQ0KPiBleHBlcnQgYnV0IG9uIEFs cGluZSwgR3VpbGUgZXh0ZW5zaW9ucyBzdWNoIGFzIGd1aWxlLXJlYWRlciBhbHNvIHNoaXAN Cj4gdmVyc2lvbmVkIHNvbmFtZXMgWzFdLg0KDQpUaGV5IGFyZSB2ZXJzaW9uZWQsIGJ1dCBB RkFJSyB0aGUgdmVyc2lvbmluZyBpcyBtb3N0bHkgbWVhbmluZ2xlc3MsIGFzIA0KKElJUkMp IHRoZSBpbnN0YWxsYXRpb24gZGlyZWN0b3J5IGZvciBHdWlsZSBleHRlbnNpb25zIGlzIHZl cnNpb25lZCANCih1c2luZyB0aGUgR3VpbGUgdmVyc2lvbikgYW5kIGFzIGxpYmd1aWxlIGRv ZXNuJ3QgdGFrZSBjYXJlIG9mIHByb3Blcmx5IA0KY2hhbmdpbmcgdGhlIHZlcnNpb24gaW4g Y2FzZSBvZiBuZXcgc3ltYm9scyBvciBpbmNvbXBhdGlibGUgY2hhbmdlcy4NCg0KVGhvdWdo IGFwcGFyZW50bHkgc29tZXRpbWVzIChlLmcuIGZvciBndWlsZS1yZWFkZXIpIGl0J3MganVz dCBwdXQgaW4gDQpbLi4uXS9saWIgLi4uDQoNCj4+ICAgICogVG8gdGVzdCBpdCwgYW5kIGF2 b2lkIGJyZWFraW5nIHRoaW5ncyBsYXRlciB3aXRoIGZ1dHVyZSBjaGFuZ2VzIHRvDQo+PiAg ICAgIGxvYWQtZm9yZWlnbi1saWJyYXJ5LCBjb3VsZCBzb21lIHRlc3RzIGJlIGFkZGVkPw0K PiBQcm9iYWJseSwgdGhvdWdoIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggdGhlIEd1aWxlIHRl c3Qgc2V0dXAgYW5kIHRoZXJlDQo+IGRvbid0IHNlZW0gdG8gYmUgYW55IGV4aXN0aW5nIHRl c3RzIGZvciBmb3JlaWduLWxpYnJhcnkuDQoNCnRlc3Qtc3VpdGUvdGVzdHMvZm9yZWlnbi50 ZXN0LCB0aG91Z2ggaXQgZG9lcyBub3QgdGVzdCBhY3R1YWxseSBsb2FkaW5nIA0KdGhlIGxp YnJhcmllcywgb25seSB0aGUgR3VpbGUgZXF1aXZhbGVudCBvZiBkbHN5bS4NCg0KSSBhbHdh eXMgZm9yZ2V0IGhvdyB0byBydW4gaW5kaXZpZHVhbCB0ZXN0cyAoaW5zdGVhZCBvZiB0aGUg d2hvbGUgc3VpdGUpIA0KbXlzZWxmLg0KDQo+PiAgICogSXMgdGhpcyBjaGFuZ2UgZGVzaXJh YmxlP8KgIEkgbWVhbiwgdGhpcyBpcyBhbiBGRkkgQVBJLCBzbyB0aGUgQUJJIG9mDQo+PiAg ICAgdGhlIGxpYnJhcnkgaXMgcmF0aGVyIGltcG9ydGFudC4gSWYgYSBHdWlsZSBtb2R1bGUg bGlua3MgdG8NCj4+ICAgICBsaWJmb28uc28sIGFuZCB0aGV5IGhhZCB2ZXJzaW9uIE4gaW4g bWluZCwgdGhlbiBpdCdzIGltcG9ydGFudCBpdA0KPj4gICAgIGRvZXNuJ3QgbGluayB0byBO LTEgb3IgTisxIGluc3RlYWQsIGJlY2F1c2Ugb2YgQUJJDQo+PiAgICAgaW5jb21wYXRpYmls aXRpZXMuIEFzIHN1Y2gsIHRvIG1lIGl0IHNlZW1zIF9nb29kXyB0aGF0IHlvdSBnb3Qgc29t ZQ0KPj4gICAgIGVycm9ycywgYXMgbm93IHlvdSBnZXQgYSByZW1pbmRlciB0byBleHBsaWNp dGx5IHN0YXRlIHdoaWNoIEFCSQ0KPj4gICAgIHZlcnNpb24gaXMgbmVlZGVkLiAoWU1NViwg YW5kIHRoZSBtaWxlYWdlIG9mIHRoZSBHdWlsZSBtYWludGFpbmVycw0KPj4gICAgIG1pZ2h0 IHZhcnksIGV0Yy4pDQo+IEluIG15IGV4cGVyaWVuY2UsIG1vc3QgbGFuZ3VhZ2VzIHdoaWNo IGRvbid0IGxpbmsgYWdhaW5zdCBzaGFyZWQNCj4gbGlicmFyaWVzIGRpcmVjdGx5IGJ1dCBp bnN0ZWFkIGxvYWQgdGhlbSBhdCBydW4tdGltZSBkb24ndCBoYXJkY29kZSBBQkkNCj4gdmVy c2lvbnMgKGZvciBleGFtcGxlLCByZWZlciB0byBQeXRob24ncyBjdHlwZXMudXRpbC5maW5k X2xpYnJhcnkpLg0KDQpIb3cgZG9lcyB0aGlzIHNob3cgdGhlICh1bilkZXNpcmFiaWxpdHkg b2YgdGhlIGNoYW5nZT8NCg0KVGhlIGZhY3QgdGhhdCBtb3N0IGxhbmd1YWdlcyBkb24ndCB0 aGF0LCBkb2Vzbid0IHNlZW0gcmVsZXZhbnQgdG8gbWUuIA0KR3VpbGUgaXMgbm90IG1vc3Qg bGFuZ3VhZ2VzLCBhbmQgdGhlIGV4cGxhbmF0aW9uIEkgZ2F2ZSBpcyBub3Qgc3BlY2lmaWMg DQp0byBHdWlsZSwgaXQgd291bGQgd29yayBqdXN0IGFzIHdlbGwgZm9yIFB5dGhvbi4NCg0K TW9yZSBnZW5lcmFsbHksIHlvdSBhcHBlYXIgdG8gYmUgaW5mZXJyaW5nICJYIGlzIGFjY2Vw dGFibGUiIGZyb20gIm1hbnkgDQplbnRpdGllcyBkbyBYIiwgaWdub3JpbmcgbXkgZXhwbGFu YXRpb24gb2Ygd2h5ICJYIGlzIG5vdCBhY2NlcHRhYmxlIi4gDQpUaGlzIGlzIGEgdmFyaWFu dCBvZiB0aGUgImFkIHBvcHVsdW0iIGZhbGxhY3kuDQoNCj4gQWxzbywgdGhlIGN1cnJlbnQg aW1wbGVtZW50YXRpb24gb2YgbG9hZC1mb3JlaWduLWxpYnJhcnkgZG9lcyBub3QgZm9yY2UN Cj4geW91IHRvIHNwZWNpZnkgYW4gQUJJIHZlcnNpb24gYnV0IGluc3RlYWQgbG9hZHMgd2hh dGV2ZXIgdGhlIGxpYmZvby5zbw0KPiBzeW1saW5rIHJlZmVycyB0by4NCkkgaGF2ZSBub3Qg bWFkZSBhbnkgcHJvcG9zYWwgdG8gY2hhbmdlIHRoaXMgYmVoYXZpb3VyLg0KDQpHcmVldGlu Z3MsDQpNYXhpbWUuDQo= --------------7TKEkSgR5EaWS4SKEfwdUj0K Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24-07-2022 14:16, S=C3=B6ren Tempel= wrote:
Hi,

Thanks for your feedback, comments below.

Maxime Devos <maximedevos@telenet.be> wrote:

Long term, I think it woul=
d be ideal for Guile to decide upon a major=20
version (and maybe even location, depending on the choices of the=20
distro) at _compile_ time instead of runtime, not unlike how other=20
compilers work.

Sure, that could work too.


If the Guile module is bei=
ng compiled with --rpath, it searches
$CROSS_LIBRARY_PATH or $LIBRARY_PATH and encodes the full file name
(/usr/lib/.../libguile-... or /gnu/store/.../lib/...) in the .go,
which avoids some manual patching we have to do in Guix.

What kind of manual patching do you do on Guix? Could you refer me to
the code for that? Maybe that's something we could also do on Alpine in
the meantime.

A few examples:

'guile-squeue' is one of the simplest examples. 

IIUC, the string-prefix? s=
earch is non-deterministic, which can make=20
debugging complicated when multiple versions are installed.=20

Well, on Linux readdir(3) file name order depends on the file system
implementation. Since the algorithm returns the first file with a
substring match, it depends on the readdir order. As long as the same
filesystem is used, it should be deterministic.

'File system-specific' is a form of non-determinism. Additionally, the file system implementation can change over time, so even if a file system is fixed in advance, it would still be non-deterministic.

Even if the file system implementation doesn't change, there can still be non-determinism. For example, if directories are implemented as hash tables and 'readdir' iterates over the buckets -- if other files are added or removed, the size changes, which can cause different hashed to be used and hence a different order. As such, the readdir order can depend on the presence and absence of other files, which seems an undesirable form of non-determinism to me.

I think it would be better=
 to bail out if there are multiple matches
instead of a risk of guessing incorrectly.

In that situation, they are all the same file, just with a different name, so in that situation it's no problem.

However, consider multiple (potentially incompatible) versions. What version do you select then? Maybe just the latest? But they might be incompatible ...


      

        
  * When doing (load-forei=
gn-library "/gnu/store/.../libfoo.so")
    (absolute file name!), would it search for
    /gnu/store/.../libfoo.so.N?=C2=A0 If so, that would be surprising,
    especially if libfoo.so.N exists.


      

      
Yep, it does. I originally didn't want to modify the handling of
absolute paths but unfortunately during testing I noticed that Guile
extensions seem to be loaded with an absolute path

    

    
I don't see what's unfortunate about that. 

    

    

      
and hence don't work without=
 the libfoo.so symlink [1].

    

    
Seems to work locally:

    

    
(load-extension=C2=A0
      "/home/antipode/.guix-home/profile/lib/libpng16.so.16" "t") ; In
      procedure dlsym: Error: ... --- though library was loaded
      succesfully.

    
It appears that load-extension already automatically adds a .so
      though (tested with (load-extension=C2=A0
      "/home/antipode/.guix-home/profile/lib/libpng16" "t"), so
      extending it to also add the .N as done here doesn't seem a
      regression to me.
    

    

      

      

        
  * If doing libfoo.so.N, =
will it search for libfoo.so.N.M?


      

      
Yes, since libfoo.so.N is a prefix of libfoo.so.N.M.

    

    
What about: =E2=80=98If doing libfoo.so.5, will it accept libfoo.s=
o.50"?=C2=A0
      libfoo.so.5 is a prefix of libfoo.so.50, so unless care is taken
      with dots, it could accept a different version than was asked for.
    

    

      

      

        
  * Does it only apply to =
the system paths, or also to
    GUILE_SYSTEM_EXTENSION_PATH, LTDL_LIBRARY_PATH and
    GUILE_EXTENSION_PATH? The latter would be surprising to me, as
    versioning is more of a system thing.


      

      
If those paths are also searched using the load-foreign-library
procedure then they are affected by this change. Also, I am not a Guile
expert but on Alpine, Guile extensions such as guile-reader also ship
versioned sonames [1].

    

    
They are versioned, but AFAIK the versioning is mostly
      meaningless, as (IIRC) the installation directory for Guile
      extensions is versioned (using the Guile version) and as libguile
      doesn't take care of properly changing the version in case of new
      symbols or incompatible changes.

    
Though apparently sometimes (e.g. for guile-reader) it's just put
      in [...]/lib ...
    

    

      

        
  * To test it, and avoid =
breaking things later with future changes to
    load-foreign-library, could some tests be added?


      

      
Probably, though I am not familiar with the Guile test setup and there
don't seem to be any existing tests for foreign-library.

    

    
test-suite/tests/foreign.test, though it does not test actually
      loading the libraries, only the Guile equivalent of dlsym.

    
I always forget how to run individual tests (instead of the whole
      suite) myself.
    

    

      

        
 * Is this change desirabl=
e?=C2=A0 I mean, this is an FFI API, so the ABI of
   the library is rather important. If a Guile module links to
   libfoo.so, and they had version N in mind, then it's important it
   doesn't link to N-1 or N+1 instead, because of ABI
   incompatibilities. As such, to me it seems _good_ that you got some
   errors, as now you get a reminder to explicitly state which ABI
   version is needed. (YMMV, and the mileage of the Guile maintainers
   might vary, etc.)


      

      
In my experience, most languages which don't link against shared
libraries directly but instead load them at run-time don't hardcode ABI
versions (for example, refer to Python's ctypes.util.find_library).


    

    
How does this show the (un)desirability of the change?

    
The fact that most languages don't that, doesn't seem relevant to
      me. Guile is not most languages, and the explanation I gave is not
      specific to Guile, it would work just as well for Python.

    

    
More generally, you appear to be inferring "X is acceptable" from
      "many entities do X", ignoring my explanation of why "X is not
      acceptable". This is a variant of the "ad populum" fallacy.

    

    

      

        
Also, the current implemen=
tation of load-foreign-library does not force
you to specify an ABI version but instead loads whatever the libfoo.so
symlink refers to.

      

      I have not made any proposal to change this behaviour.

    

    Greetings,

    Maxime.

  


--------------7TKEkSgR5EaWS4SKEfwdUj0K--

--------------0SdRp0NCFPS8AY0fP1W0V0bE
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------0SdRp0NCFPS8AY0fP1W0V0bE--

--------------c11BUmnRC3DcQe0RBR0rIUIW--

--------------hRYIOB5x8etmL3n1jK5Hv5bo
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYwEoKwUDAAAAAAAKCRBJ4+4iGRcl7nrm
AP4qix5qTZKi7S6ezZDcNZA/FGe9hKWzYZOwOqtmiTBe/QD/RXWNRuIZI9IFj6uaIeOm/Z8EfgEB
N0oDlfqKZV8edwY=
=wIS3
-----END PGP SIGNATURE-----

--------------hRYIOB5x8etmL3n1jK5Hv5bo--




From unknown Sat Jun 14 03:57:28 2025
X-Loop: help-debbugs@gnu.org
Subject: bug#49232: [PATCH] load-foreign-library: perform substring match on library files
Resent-From: Maxime Devos 
Original-Sender: "Debbugs-submit" 
Resent-CC: bug-guile@gnu.org
Resent-Date: Sat, 20 Aug 2022 18:31:02 +0000
Resent-Message-ID: 
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 49232
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?S=C3=B6ren?= Tempel 
Cc: 49232@debbugs.gnu.org, guile-devel@gnu.org
X-Debbugs-Original-Cc: bug-guile@gnu.org, guile-devel@gnu.org
Received: via spool by submit@debbugs.gnu.org id=B.166102025828612
          (code B ref -1); Sat, 20 Aug 2022 18:31:02 +0000
Received: (at submit) by debbugs.gnu.org; 20 Aug 2022 18:30:58 +0000
Received: from localhost ([127.0.0.1]:33510 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from )
	id 1oPTFJ-0007RQ-Sk
	for submit@debbugs.gnu.org; Sat, 20 Aug 2022 14:30:58 -0400
Received: from lists.gnu.org ([209.51.188.17]:33988)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from ) id 1oPTFI-0007RJ-7V
 for submit@debbugs.gnu.org; Sat, 20 Aug 2022 14:30:56 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47790)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from )
 id 1oPTFI-0008TQ-2H
 for bug-guile@gnu.org; Sat, 20 Aug 2022 14:30:56 -0400
Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]:55458)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from )
 id 1oPTFG-0002m3-JU
 for bug-guile@gnu.org; Sat, 20 Aug 2022 14:30:55 -0400
Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]
 ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
 by laurent.telenet-ops.be with bizsmtp
 id 9uWr2800N20ykKC01uWsvg; Sat, 20 Aug 2022 20:30:52 +0200
Message-ID: <9da35cf8-c401-bf69-46b7-fcdcf8db5cc8@telenet.be>
Date: Sat, 20 Aug 2022 20:30:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net>
 <20220723110919.30107-1-soeren@soeren-tempel.net>
 <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be>
 <2EA1MELO27342.28JGAL8QO05T4@8pit.net> <27GGIELIPN05K.2DRSYZVI36WYY@8pit.net>
From: Maxime Devos 
In-Reply-To: <27GGIELIPN05K.2DRSYZVI36WYY@8pit.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------7hfyPvq0H06NdBb8dOnghanJ"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
 t=1661020252; bh=Kun5OFEzOHtWO0OMlAZWrwkgAiaaqWWFJORpZXFMl4A=;
 h=Date:Subject:To:Cc:References:From:In-Reply-To;
 b=RmedozhKmvvGIllSxqDdO8obhglzzGitJ/IUxPJsnL+DWu+af9y5vkUmL7Fr1uL4I
 93EaYlL5hNZmKdjOXJIwEQNcE42cpzdaUPeF6sZv8Q0rOpTwU/Y7MsNOfw0rgW6Vx/
 60+kvRrI2umZrd2gWkpogVcFuVTjxexYLhrtyaCF4L1sP+Xw5Pmyv5ZXFqUf3MuOjT
 rLvzdmIZ5xtsd8/OeT21JCP+6Y6nzUNIFyZG4JHzSVSEti8qCej8dxaGQT3f5dgZ/T
 KIco9s9NSbhGCtFOMwG6aied75jFhC1/Nc0PaGhvQfAZDn34UFXVJbXbwC3osk1yYM
 0xldz+AjgoQoA==
Received-SPF: pass client-ip=2a02:1800:110:4::f00:19;
 envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: 
List-Unsubscribe: , 
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
 
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" 
X-Spam-Score: -2.3 (--)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------7hfyPvq0H06NdBb8dOnghanJ
Content-Type: multipart/mixed; boundary="------------Zozoy0x0xaW4vmpBU351C5JD";
 protected-headers="v1"
From: Maxime Devos 
To: =?UTF-8?Q?S=c3=b6ren_Tempel?= 
Cc: bug-guile@gnu.org, guile-devel@gnu.org
Message-ID: <9da35cf8-c401-bf69-46b7-fcdcf8db5cc8@telenet.be>
Subject: Re: [PATCH] load-foreign-library: perform substring match on library
 files
References: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net>
 <20220723110919.30107-1-soeren@soeren-tempel.net>
 <936e98a7-a9d2-2607-ef6a-8c0edff19c4a@telenet.be>
 <2EA1MELO27342.28JGAL8QO05T4@8pit.net> <27GGIELIPN05K.2DRSYZVI36WYY@8pit.net>
In-Reply-To: <27GGIELIPN05K.2DRSYZVI36WYY@8pit.net>

--------------Zozoy0x0xaW4vmpBU351C5JD
Content-Type: multipart/mixed; boundary="------------P003IZA1yT0KtCtOhlCoIhT6"

--------------P003IZA1yT0KtCtOhlCoIhT6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

DQpPbiAyMC0wOC0yMDIyIDE1OjUyLCBTw7ZyZW4gVGVtcGVsIHdyb3RlOg0KPiBIaSwNCj4N
Cj4gSG93IGRvIHdlIHByb2NlZWQgd2l0aCB0aGlzPw0KPg0KPiBJIHdvdWxkIGVzcGVjaWFs
bHkgYmUgaW50ZXJlc3RlZCBpbiB0aGUgInBhdGNoaW5nIiB0aGF0IHlvdSBkbyBpbiBHdWl4
Lg0KPiBNYXliZSB0aGF0IHdvdWxkIGFsc28gYmUgYSBzdWl0YWJsZSB3b3JrYXJvdW5kIGZv
ciB1cyBvbiB0aGUgQWxwaW5lIHNpZGUNCj4gdW50aWwgdGhpcyBpcyBzb3J0ZWQgb3V0IHBy
b3Blcmx5Lg0KPg0KPiBHcmVldGluZ3MsDQo+IFPDtnJlbg0KDQpFdmVudHVhbGx5LCBhbiBh
Y3R1YWwgR3VpbGUgbWFpbnRhaW5lciBuZWVkcyB0byBwb3AgdXAuIEknbSBub3Qgb25lIG9m
IHRoZW0uDQoNCkdyZWV0aW5ncywNCk1heGltZS4NCg0K
--------------P003IZA1yT0KtCtOhlCoIhT6
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------P003IZA1yT0KtCtOhlCoIhT6--

--------------Zozoy0x0xaW4vmpBU351C5JD--

--------------7hfyPvq0H06NdBb8dOnghanJ
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYwEoWwUDAAAAAAAKCRBJ4+4iGRcl7tjp
AP9FRMzukRRu7pojEepq81+qBthJKs9qruuhJ7fIaJ/I4wEAiAYF61LGMmj9ls7E45e36IYRGzwe
I2f3/ZP4+qT/rg4=
=PPG9
-----END PGP SIGNATURE-----

--------------7hfyPvq0H06NdBb8dOnghanJ--