From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: ccall mechanism in Julia Date: Fri, 6 Mar 2015 16:48:59 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTuUy-0002df-7X for guix-devel@gnu.org; Fri, 06 Mar 2015 10:49:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTuUu-0006y5-1R for guix-devel@gnu.org; Fri, 06 Mar 2015 10:49:12 -0500 Received: from pegasus.bbbm.mdc-berlin.de ([141.80.25.20]:54381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTuUt-0006xn-OV for guix-devel@gnu.org; Fri, 06 Mar 2015 10:49:07 -0500 Received: from localhost (localhost [127.0.0.1]) by pegasus.bbbm.mdc-berlin.de (Postfix) with ESMTP id 1E58838057E for ; Fri, 6 Mar 2015 16:49:06 +0100 (CET) Received: from pegasus.bbbm.mdc-berlin.de ([127.0.0.1]) by localhost (pegasus.bbbm.mdc-berlin.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pOQxTMShXzX for ; Fri, 6 Mar 2015 16:48:59 +0100 (CET) Received: from HTCATWO.mdc-berlin.net (puck.citx.mdc-berlin.de [141.80.36.101]) by pegasus.bbbm.mdc-berlin.de (Postfix) with ESMTP for ; Fri, 6 Mar 2015 16:48:59 +0100 (CET) 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: Guix-devel Hi Guix, I'm currently packaging up Julia, a programming language for technical computing. When I configure the build process such that system libraries are used instead of the bundled copies I run into a problem. 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. Before I hack a little more on the sources to implement a solution that also considers libraries that happen to lie around in ~/.guix-profile/lib I would like to ask for comments. Would it be a very bad idea if I wrote a simple replacement for "ldconfig -p" that returned all libraries in the user's profile? I don't think this would be as bad as breaking the FFI and hard-coding build-time paths to inputs. What do you think? ~~ Ricardo