Closed GoogleCodeExporter closed 9 years ago
You can set LD_LIBRARY_PATH when you invoke the child process. Just tell the
RuntimeProvider to deploy the shared libraries (via the manifest), then get
their locations and add them to the LD_LIBRARY_PATH.
It would probably be best if RuntimeProvider offered convenience methods for
this. Feel free to open an issue in DKPro Core.
Original comment by richard.eckart
on 4 Mar 2015 at 8:38
Even better: recompile the 32bit library statically. I did that once for the OS
X binary:
https://code.google.com/p/cleartk/issues/detail?id=314
Maybe you can use the binaries that ClearTK uses? I think they are all
statically linked.
Original comment by richard.eckart
on 4 Mar 2015 at 8:43
The binary I use is taken from ClearTK. Expect the linux 32 bit one they are
all linked statically.
I tried to compile it myself, but this "Constant Quark Database" which is also
distributed by the crfsuite developer is missing when compiling and I don't
really get what is have to do to fix it.
Original comment by Tobias.H...@gmail.com
on 4 Mar 2015 at 9:38
Re-Compiling the binary does not work.
What would I have to do to follow the LD_LIBRARY_PATH way?
What exactly would i have to do to tell the runtime provider to provide me with
the libraries?
At the moment I just call the runtime provider and ask for the 'crfsuite'
binary.
I would include the libraries file in an own subfolder would calling the
runtime provider with the folder name work?
Original comment by Tobias.H...@gmail.com
on 4 Mar 2015 at 10:19
The provider installs all files mentioned in the manifest to a temporary
location (runtimeProvider.getWorkspace()). If the manifest specifies a file as
"executable", the runtime provider makes it executable. The other files just
just around. If you set LD_LIBRARY_PATH to runtimeProvider.getWorkspace(), I
guess it should work. Setting the LD_LIBRARY_PATH should be possible through
processBuilder.environment().put("LD_LIBRARY_PATH",
runtimeProvider.getWorkspace().getAbsolutePath()).
Original comment by richard.eckart
on 4 Mar 2015 at 10:38
I think the single static executable would still be the best solution.
As it is now, I would have to set this library information at start up of the
process. This is something I only would have to do for the linux 32 bit binary.
All other projects that might want to use the binary directly for instance the
model loading/reusing would have to be extended to be aware of this optional
step of setting the LD_* variable.
Who cares about 32 bit linux anyway ... I would rather leave it as is. I am not
sure what the issue is with the libraries that are not found when I am
compiling crfsuite in my virtual machine, but it seems not really worth the
effort...
Original comment by Tobias.H...@gmail.com
on 4 Mar 2015 at 11:25
Curse Ubuntu, praise Debian. I managed to get a static 32-bit linux vesion
compiled. I updated the binary.
Original comment by Tobias.H...@gmail.com
on 4 Mar 2015 at 3:35
Original issue reported on code.google.com by
Tobias.H...@gmail.com
on 4 Mar 2015 at 8:33