Is it possible to compile tesseract into one binary?
I use the following to compile a program, but how is it possible to compile tesseract shared libraries into one binary so the program is 100% portable and you dont need tesseract to be installed on the current system?
Its not necessary to compile leptonica into the binary
g++ -std=c++11 txtocr.cpp -o txtocr -llept -ltesseract
For that you need to use a Static Library, on unix systems they usually ends with the .a extension, and a Shared Library ends with .so
If you only have the .so (or .dylib on mac, .dll on windows) library of the tesseract, then you cannot compile it as a single binary.
Use the -static argument to g++ to compile a static binary.
Try pyInstaller, it support Windows, Linux and OSX. Below sample command is to create an one file bundle executable.
pyinstaller -F /path/to/myscript.py
It can be installed by pip install pyinstaller, or use MacPorts or Homebrew to install in OSX.
This link below
https://github.com/tesseract-ocr/tesseract)
will help you more. Whether you are going to compile from scratch or uselibraries which are already compiled for you for the desired OS.
Related
In my C++ project, I'm compiling and linking against a library that makes use of OpenSSL.
I need to compile this project for my BeagleBone which has openssl installed by default. I have downloaded libssl-dev on my development machine.
Thus, I can compile the project fine if I'm compiling for my development machine on x86_64, but I am not able to successfully cross compile:
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lssl
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lcrypto
This indicates I need to have armhf binaries for OpenSSL, which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it.
Is the only way around this cross-compiling OpenSSL myself? Where would I then need to install the .so files (I guess make install would be a bad idea?)
This indicates I need to have armhf binaries for OpenSSL
Correct.
which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it.
You appear to think that shared libraries are only needed at runtime, but that is not the case.
ELF stands for executable and linking format. The .so is very much needed at static link time to construct various tables in the main executable, which will then be used by the loader at runtime to resolve references from the main executable to the .so.
If you are familiar with Win32, you can think of .so as a combination of Win32 .LIB and .DLL packed into a single file.
I use TextPad and MinGW. I compile with TextPad so I don't know how to use gcc ect. comands.
I got my library from here ftp://ftp.gnu.org/gnu/gsl/gsl-1.9.tar.gz and I have no idea what to do with it. In my MinGW folder there are bin, include and lib folders of course but I have no idea what to copy where.
And I don't know how to find out where MinGW searches for these libraries.
It would seem reasonable to copy .h , .a and .dll files where such files already are. It doesn't help that supposedly the same gsl are different from source to source and some include .dll and some don't.
I suppose the biggest problem is how do I tell MinGW where to search, since I found gsl that is already compiled and I could supposedly already use.
Assuming you have MSYS accompanied with MinGW, you can simply do:
./configure
make
make install
after
tar xzf gsl-1.9.tar.gz
cd gsl...
It will install gsl to the default directories. You may have to use -I/usr/local/include -L/usr/local/lib on the command line when compiling your program using gcc, because MinGW gcc does not recognize those standard locations.
C++-Protobuf does not compile in VS2012. Now I want to use MinGW to compile it on windows. Can someone please give me some brief headwords on how to compile protobuf on Win7 x64. I already installed MinGW with the GUI installer. Google writes as MinGW setup notice that I should refer to the Unix installation notes. But I cant figure out how to use the auto tools on windows.
Edit
Okay this is what I've done until now:
$ mount C:/ WinDir
$ cd ./[...]/protobuf.2.4.1
$ ./configure
$ minGW32-make.exe
$ minGW32-make.exe check
minGW32-make.exe runs without errors, but no tests are running and I cant find libprotobuf.lib. There are some libprotobuf.dll but I need the lib, dont I?.
You should have an MSys console together with your MinGW instalation. This console provides an linux-like environment in which you should be able to use autotools normally.
If MSys is not installed, you can grab it from the MinGW site too.
cd to your directory with sources and try the usual:
$ ./configure
$ make
Some libraries cause problems on Windows but most compile well with MinGW and MSys. Come back and add more info to your question if you run into specific problems.
Edit:
minGW32-make.exe runs without errors, but no tests are running and I cant find libprotobuf.lib. There are some libprotobuf.dll but I need the lib, dont I?.
Usually for a dynamic library you'd get protobuf.dll (the dynamic library) and libprotobuf.a (the static wrapper library).
When linking, just pass -lprotobuf to the linker - it will look for both libprotobuf.a and protobuf.lib.
(.lib is another static library format, which is partially handled by MinGW but not native here.)
You will not work with a .lib file when using the MinGW toolchain. Instead, you are able to link against the dll directly. The MinGW Wiki explains this.
I could get dll and lib both. This is when you do not want static lib file and want to use dll and lib file.
You need to make following changes in Protobuf code:
Open the project in VS. Or any other editor. I use VS2015.
In libProtoBuf project settings, in C/C++ Preprocessor add following flags.
PROTOBUF_USE_DLLS; LIBPROTOBUF_EXPORTS;
Those flags will export information from profobuf using dllexport
in ur client code where you are using Protobuf, define: PROTOBUF_USE_DLLS. Which will make protobuf includes to use dllimport.
Once you do step 2, you will see both dll and lib in your output folder. Otherwise, you will always see just dll and not lib file.
Hope this helps. If not, please write a message here and I can help you getting this sorted out.
I'm cross-compiling a C++ program. But when I try to run on the target computer it can't find the C++ libs (namely libstdc++.so.5).
Is there a way to bundle all the dependencies so I can run on the target computer?
Or do I have to install them on the target computer?
Try g++ -static x.cc -o x. This will link all of your libraries, including libstdc++, into your executable.
Of course, the resulting image will be larger than a dynamically-linked image.
I'm trying to use a Python library (pyMedia) that has some non-Python requisites libraries. (libogg, libvorbis, liblame, and libfaad2 - this isn't relevant to the question specifically).
libogg requires you to manually compile it from the source and comes with a makefile. I have GCC installed for Windows. How would I go about compiling this?
Get cygwin. It's the unix environment for windows, along with the Autotools (including make) toolchain.
MinGW can be used to compile under Windows. Add the binary to the PATH environment variable and you can use mingw32-make to compile using the Makefile.