I'm trying to install OpenALPR on Laravel Homestead (Ubuntu 18.04). First I tried The Easiest Way. I'm trying to run:
Error opening data file /usr/share/openalpr/runtime_data/ocr/lus.traineddata
Please make sure the TESSDATA_PREFIX environment variable is set to your "tessdata" directory.
Failed loading language 'lus'
Tesseract couldn't load any languages!
Segmentation fault (core dumped)
I cd into /usr/share/openalpr/runtime_data/ocr directory, and I did not find the lus.traineddata file. But there was an ocr folder and there was a lus.traineddata. I copied it from there to the directory up, tried again to recognize but this time:
--(!) Runtime directory '/usr/share/openalpr/runtime_data' is invalid. Missing OCR data for the country: 'us'!
Error loading OpenALPR
Then I tried The Easy Way. Everything was compiled normally. But:
Segmentation fault (core dumped)
This happens because openALPR's Tesseract OCR expects its trained data in a specific path and the files are not there.
According to the error message it can be set using the TESSDATA_PREFIXenvironment variable but in my own experience didn't work.
I came accross with nother solution; it's not the best way but it may work.
I created a symbolic link from /usr/share/openalpr/runtime_data/ocr/tessdata/lus.traineddata to /usr/share/openalpr/runtime_data/ocr/lus.traineddata in order to make the trainedData files available to tesseract/openalpr right where they expect them.
sudo ln -s /usr/share/openalpr/runtime_data/ocr/tessdata/lus.traineddata /usr/share/openalpr/runtime_data/ocr/lus.traineddata
repeat the command changing lus with the desired language/region file (leu, lfr, ...)
Hope it helps
This is because the language trained data is in [runtime_data path]/ocr/tessdata/ in tesseract 4.0 unlike tesseract 3.0 which stores them in [runtime_data path]/ocr/.
This problem is fixed in this commit.
But it seems that the version of openalpr in the apt-get repository is behind this commit.
So the temporary solution is moving language data to [runtime_data path]/ocr like danielillu’s solution.
Since ‘us’ country config only require lus.traineddata file, you only need to move lus.traineddata file.
Related
I recently went to try to debug a program with GDB and got the following error:
gdb: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory
So I went investigating and tried the obvious things, ie sudo apt-get install libncursesw5 (and dev variants) and apt reports that I've already got the latest version...so next I tried reinstalling GDB, problem persists. The output of ldd with GDB confirms to me that it still doesn't know where this mythical libncursesw.so.6 file is, so I go digging around in the usr/lib/x86_64-linux-gnu folder and run ls libncu* which returns six results: libncurses.a, libncurses++.a, libncurses.so, libncurses++w.a, libncursesw.a, and libncursesw.so...but no libncursesw.so.6. I then naively attempted to just make a copy of libncursesw.so named libncursesw.so.6, to which gdb reports that this file is "too short".
In googling I can't seem to find a good explanation on how to get this file in place? Every other answer I see just suggests running sudo apt-get install libncursesw5 (or something similar) but I've already tried pretty much every variant of that I can think of. I was going to remove it and then reinstall it but when I went to do that it gave me a scary warning that I could be doing something potentially harmful to my system so I aborted that idea.
Some context that also might(?) help:
I'm running a pretty recent install of Linux Mint 19.3 Cinnamon, and this was my first time trying to run GDB on my new computer. I basically set this new computer up as a new install, just porting over my home directory and a couple of the more useful hidden . files from my old laptop...I figure this shouldn't be the reason GDB is failing/these files don't exist on the new machine but just in case I'm mentioning it.
obvious things, ie sudo apt-get install libncursesw5
You want libncursesw6, not libncursesw5.
I have an OCaml program that worked fine on Ubuntu 16 but when recompiled and run on Ubuntu 20 I get the following error:-
$ ocamldebug ./linearizer
OCaml Debugger version 4.08.1
(ocd) r
Loading program... done.
Time: 89534
Program end.
Uncaught exception: Sys_error "Illegal seek"
(ocd) b
Time: 89533 - pc: 624888 - module Netaccel_link
No source file for Netaccel_link.
I thought this was due to missing dev libraries but:-
$ sudo apt install libocamlnet-ocaml-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libocamlnet-ocaml-dev is already the newest version (4.1.6-1build6).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
What setup step am I missing on Ubuntu 20?
This looks like a regression bug in libocamlnet and you should report an issue there or, I am a bit pessimistic that you will get any response, you can try to debug the issue yourself.
The problem that you are facing has nothing to do with missing libraries (they will be reported during installation or, if the package is broken, end up in linker errors). It may result, however, from some misconfiguration of the system. If that is true, then you're lucky as you can fix it yourself.
I will give you some advice that might help you in debugging this issue. For more, please try using discuss.ocaml.org as a more suitable media (SO doesn't favor this kind of a discussion and we might get deleted by admins).
The illegal seek exception is thrown when the seek operation is applied on a non-regular file, aka ESPIPE Unix error. So check your inputs. It could be that what was previously regarded as a file in Ubuntu is now a pipe or a socket.
Try to use ltrace or strace to pinpoint the culprit e.g.,
ltrace ./linearizer
or, if it overwhelms you, try strace
strace ./linearizer
Instead of using ocamldebug you can use plain gdb. You can use gdb's interfaces to provide the path to the source code (though most likely it won't work since ocamlnet is not compiled with debug information). I believe that it will give you a more meaningful backtrace.
Instead of using the system installation try using opam. Install your dependencies with opam and try older versions as well as newer versions of the OCaml compiler. Also, try different versions of ocamlnet. Ideally, try to reproduce the environment that used to work for you.
When nothing else works, you can use objdump -d and look at the disassembly of your binary. OCaml is using a pretty readable and intuitive name mangling scheme (<module_name>__<function_name>_<uid>), so you can easily find the source code (search for <module_name>.ml file and look for the <function_name> there)
Finally, just use docker or any other container to run your application. Consider switching from ocamlnet to something more modern and supported.
If I start gdb -tui or gdbtui with an -g flag compiled file, then set b main and press r I get the hint dl-debug.c:74 no such file or directory and the output while stepping through the source window will be written to the source window at the bottom, which also messes up this window so that is not really readable. I've already looked at askubuntu.com and Sourceware Bugzilla – Bug List and at this site but found no solution.
I also tried out sudo apt-get install ddd on another machine to go to the trouble out of the way, but then I only get authentication failure, which I also already asked without response on ask ubuntu.
Any help or hint is appreciated.
dl-debug.c:74 no such file or directory
This message means that you've tried to step into GLIBC (more precisely the dynamic loader) source, which you didn't install.
Solution: don't try to step into it, or install GLIBC source and make GDB find it (help directory).
I am getting an error:
"Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries"
The error arises when I try to execute my exe file.
I have created exe file through pyinstaller on a django application. Application uses pylucine library. I think it may be the issue of error.
How to fix the error?
Since I can't be certain given you've provided very few details here is a shot in the dark to help solve your problem:
First, try removing the jvm.dll file that gets packaged with the pyinstaller -D youmodule.py command (for now work with the directory command rather than -F option). The reason why is here.
With that jvm.dll file gone, you should start seeing the actual error code - and with that the java class or dependency that isn't being loaded.
If it's a java class that isn't being properly loaded then you know instantly it must not be correcly represented in the classpath environment variable and you should do everything in your power to make sure it is:
e.g.: os.environ['CLASSPATH'] += 'the/path/to/the/jar'
Otherwise, consider bulking up your question with more details, especially if you can get a more meaningful error output.
I had the same error trying to run a .exe built with PyInstaller through wine.
My problem went away by adding C:\Program Files\Java\ [your jdk version here] \jre\bin\server to the PATH environment variable in wine - I suppose it might be the same in Windows.
It also reappeared if I tried to build with C:\Program Files\Java\ [your jdk version here] \jre\bin\server in my PATH, so I had to build without it and then append it before running it (I have no explanation as to why this happens).
I'm writing a C++ project that will occasionally use a system call to Weka to get some machine learning information. First I'd like to ensure that the training model (training.model) is up to date. So, at the beginning of main, I call:
system("\"java weka.classifiers.trees.J48 -t ML_data.arff -d training.model\"");
That gives Error: could not find or load main class weka.classifiers.trees.J48. I know what that means, so I moved the entire Weka project folder, entitled Weka-3-6, to the directory in which my project is found. So then I tried:
system("\"java \Weka-3-6\\weka.classifiers.trees.J48 -t ML_data.arff -d training.model\"");
But that returns Error: could not find or load Weka-3-6\weka.classifiers.trees.J48.
I feel like I'm in the right neighborhood, but I can't get the slashes right, and I'd prefer not to mess with absolute paths because the folders have spaces and that makes it even messier. Any ideas? Help is greatly appreciated.
Open a terminal/cmd prompt and try to run your command in your terminal/cmd prompt. Following is an example cmd batch script for windows. Your problem is most likely java classpath settings not weka problem. If you succeed in following command, then try your command with again in c++.
SET WEKA_HOME=C:\Program Files\Weka-3-7
SET CLASSPATH=%CLASPATH%;%WEKA_HOME%\weka.jar
SET HEAP_OPTION=-Xms4096m -Xmx8192m
SET JAVA_COMMAND=java %HEAP_OPTION%
%JAVA_COMMAND% weka.core.SystemInfo