Sorry, I didn't explain that well.
It is the location of deps/deps.jl that is not at a constant location
_relative_ to the current working directory, which could be anything. I
can't hard code it to an absolute path since that will just break on
someone else's machine.
The whole point of the deps/deps.jl fix suggested n the post above was to
get around the fact that your external libraries might be in directories
that can only be known at runtime, so you get build.jl to write them into
deps/desp.jl and include it.
But deps/deps.jl is also at a location that can only be known at runtime.
Catch 22.
I have to insert a cd() before include("deps/deps.jl") and need a different
directory on Windows to Linux and lots of nasty things like that. Not to
mention needing to pull apart the strings for the directories and insert
\\\\ everywhere in build.jl when writing the directories out to the file
deps/deps.jl so that they end up double quoted in deps/deps.jl. It just
seems like an extremely messy solution to a simple problem.
And then there's the problem that on Windows, directories apparently can't
contain ".." as they can on Linux. So you have to canonicalise them, which
means more manipulation, etc.
What I was essentially suggesting is that we need a version of include that
includes files relative to a given package dir. Yes, you can make such a
directory yourself out of Pkg.dir("Mypackage"), etc. But then this is not a
constant directory and so apparently can't be done from within __init__, at
least not with precompilation enabled. In such a location, you apparently
need constant strings.
I did manage to make all this work in the end, but the code I ended up with
feels pretty messy.
As for Libdl.DL_LOAD_PATH, I am setting that. But again, (at least in the
presence of precompilation), Julia is no longer able to find the libraries
when called from __init__. Just setting Libdl.LD_LOAD_PATH in __init__ (or
elsewhere) does not fix this problem. The libraries still require explicit,
constant, canonicalised, absolute paths in the ccalls and cglobals in
__init__, unlike anywhere else in Julia.
Sorry, that seems like a rant. It's not intended to be. I'm just trying to
list some of the issues.
I appreciate there are some limitations on what is actually possible. But
at present, it's really hard to find any solution, which makes it seem like
there must be a better way.
Bill.
On 18 September 2015 at 20:27, Jameson Nash <[email protected]> wrote:
> > * putting const library name strings in deps/deps.jl is problematic
> because the working directory may be different depending on whether you are
> running the module test suite or just using the module from the Julia
> console.
>
> presumably running the code in the code from the test suite and running it
> from the console shouldn't be rearranging your filesystem? regardless, the
> intent behind Libdl.DL_LOAD_PATH was to help handle this case.
>
>
> On Fri, Sep 18, 2015 at 10:13 AM Bill Hart <[email protected]>
> wrote:
>
>> I managed to get it to work. The problem was obscure.
>>
>> * the patch someone had come up with for putting the -rpath in libpari
>> was faulty
>> * I thought libgmp.so.16 was resolving (when I did ldd) because part of
>> the procedure to put the -rpath in the library was to put the library path
>> in LD_LIBRARY_PATH
>> * I was running Julia itself from a different terminal, where
>> LD_LIBRARY_PATH was not set.
>>
>> So that problem is fixed. I can now initialise the Pari library from
>> within __init__.
>>
>> Two issues remain:
>>
>> * the rpath was not needed in the library to run pari_init in the libpari
>> library from outside __init__, only from inside (I checked this carefully).
>>
>> * putting const library name strings in deps/deps.jl is problematic
>> because the working directory may be different depending on whether you are
>> running the module test suite or just using the module from the Julia
>> console.
>>
>> It would be nice to have a mechanism for including files from a given
>> module with a constant string describing the location of the file to
>> include, no matter what the current directory happens to be.
>>
>> As always, thanks for the help.
>>
>> Bill.
>>
>
