google-code-export / dkpro-tc

Automatically exported from code.google.com/p/dkpro-tc
Other
1 stars 0 forks source link

CRFSuite: Linux 32 bit binary needs static/shared libraries #233

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The 32 bit linux executable of CRFsuite needs static/shared libraries.

I used the binary before (outside of TC) and had to set the LD_LIBRARY_PATH 
environmental variable to point to the directory with the needed libraries in 
order to execute the binary. 

At the moment I just call the runtime provider class to load the main binary. 
What would be the best way to implement setting this environmental variables? 

Original issue reported on code.google.com by Tobias.H...@gmail.com on 4 Mar 2015 at 8:33

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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