From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs ffi (was: Re: as for Calc and the math library) Date: Thu, 15 Aug 2024 12:43:03 +0300 Message-ID: <86frr66s0o.fsf@gnu.org> References: <864j7qhup6.fsf@gnu.org> <87a5hi0yts.fsf@valhala.localdomain> <86y152ge0b.fsf@gnu.org> <86jzgjfwqp.fsf@gnu.org> <87sev78arx.fsf@gmail.com> <86le0z89u1.fsf@gnu.org> <87o75v87n1.fsf@gmail.com> <86frr786k7.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7871"; mail-complaints-to="usenet@ciao.gmane.io" Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 15 11:44:02 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1seX1V-0001rB-Hg for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Aug 2024 11:44:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1seX0f-0000nt-6o; Thu, 15 Aug 2024 05:43:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1seX0c-0000nV-MN for emacs-devel@gnu.org; Thu, 15 Aug 2024 05:43:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1seX0c-0007ko-17; Thu, 15 Aug 2024 05:43:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hvUhIqLXdafzefiJaxWpQiQ/U1VzWThZjyoarVy921U=; b=Fdx/MSZk6ui9 wTWSuJY7UhqaN8FO5+RyoI0bySQ/1HxHIT2eMLSRdqSn74ybWcxjoPS0HwfI0qT+0l6KIpmG5hRns S5N/hbKRZX0oU8COB6axkfbEvYOq1PbnAb0eXSfprR9vVy+HWqECL2/GFnXlxcFVkgJ/aaIglBM1D 5BT5bPc287CVHd75qi67XnOV0dfrvYloiYSqZ36Scw36wwdLe2dG7ybA62Ud5wFsq+nB9X7zt99n3 MGjqWffnVoMSsEFCuGIDlprxWc/u3epQ3GKdFhaQ0BRjEAbYled8sgVdZWpOmKcL7UIgSRzx/hBRK LJ+jGbJwB32omkflGNlAng==; In-Reply-To: (message from Andrea Corallo on Thu, 15 Aug 2024 05:31:49 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322778 Archived-At: > From: Andrea Corallo > Cc: Suhail Singh , gerd.moellmann@gmail.com, > nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org > Date: Thu, 15 Aug 2024 05:31:49 -0400 > > Eli Zaretskii writes: > > > The way we do it when loading modules requires the _loaded_ library to > > declare itself compatible, by exporting a symbol of a certain name. > > That is an action by the library we load, not by the Lisp program > > which loads it. > > But we could do the same for our hypothetical ffi machinery, that is: > `define-ffi-library' could fail if the shared library is not exporting > the predetermined symbol we expect no? Of course. But how many such libraries do that? You are in effect talking about libraries specifically written or adapted for this hypothetical FFI machinery that is Emacs- or at least GNU-specific. Whereas the main motivation behind the request is to allow loading arbitrary libraries out there that already exist and definitely don't export any such symbols. At the very least, the interested individual will have to fork the library, verify it has a GPL-compatible license, modify its code to export such a symbol, and then rebuild it. So, while this arrangement is definitely possible and okay for Emacs, I very much doubt that it will be practical enough to be of use. Nevertheless, if someone submits such an implementation of such FFI machinery, I see no obstacles to accepting it (except the usual: clean code, good documentation, etc.).