[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ccall mechanism in Julia
From: |
Ricardo Wurmus |
Subject: |
Re: ccall mechanism in Julia |
Date: |
Sun, 8 Mar 2015 15:35:39 +0100 |
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