[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ccall mechanism in Julia
From: |
Ricardo Wurmus |
Subject: |
ccall mechanism in Julia |
Date: |
Fri, 6 Mar 2015 16:48:59 +0100 |
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
- ccall mechanism in Julia,
Ricardo Wurmus <=