From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: ccall mechanism in Julia Date: Sun, 8 Mar 2015 15:35:39 +0100 Message-ID: <87egoz8slg.fsf@mango.localdomain> References: <20150306222516.GA2650@debian> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUcJ5-00052u-PI for guix-devel@gnu.org; Sun, 08 Mar 2015 10:35:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUcJ2-0005Dz-Hf for guix-devel@gnu.org; Sun, 08 Mar 2015 10:35:51 -0400 Received: from pegasus.bbbm.mdc-berlin.de ([141.80.25.20]:57981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUcJ2-0005DO-4M for guix-devel@gnu.org; Sun, 08 Mar 2015 10:35:48 -0400 In-Reply-To: <20150306222516.GA2650@debian> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: Guix-devel Andreas Enge writes: > On Fri, Mar 06, 2015 at 04:48:59PM +0100, Ricardo Wurmus wrote: >> Julia's bindings to these libraries use the ccall mechanism; ccall >> builds a map from library names to paths by parsing the output of >> "ldconfig -p" at runtime. I worked around this problem by patching the >> sources to include a static map of library names to store paths. Then I >> noticed, however, that my patch effectively cripples the FFI. It is no >> longer possible to call a function that is exported by a shared library >> unless it happens to be in the static map that is created at build time. > > This looks like a good approach for guix, where we try to not use random > libraries lying around in the user profile. Setting the rpath with our > ld-wrapper behaves also like a static map. Otherwise, updating some other > library in the user profile would modify the behaviour of julia, which > would contradict our functional approach. The problem I see is that a user won't be able to make foreign function calls to installed libraries at runtime in an interactive Julia session. With Guile I'm not limited in this manner because I can arbitrarily extend the GUILE_LOAD_PATH and use stuff that's not installed to the store. With C I can extend the paths as well and compile stuff that are not in the store, in an exploratory fashion. If we went with a static map of only the most rudamentary compile-time dependencies users won't be able to use the flexible FFI in an ad-hoc manner, severely limiting expression. I would still want to hard-code the paths of input librarie providing core features so that the behaviour of Julia would not change dependent on what libraries are installed, but I think that we should avoid disabling the FFI for anything but the core libraries. I would like to extend the ccall mechanism such that one could make foreign function calls to installed libraries (or libraries available in some list of paths). >From what I can tell Julia's FFI requires no boilerplate. A user just needs the library name (or rather the key in the sonameMap resolving to a library path) and the function name to access. I would very much like to keep this feature. How are Guile's or Python's FFI handled? ~~ Ricardo