LimeReport compilation: Error 127. What causes this? - c++

I am trying to compile LimeReport in Windows 10 using Qt 5.5.9 and Qt Creator 4.11.0. I get the following compilation output and the compilation stops.
/usr/bin/sh: I:\Programs\Qt\Qt5.9.9\5.9.9\mingw53_32\bin\lupdate.exe: command not found
Makefile.Debug:762: recipe for target 'ts' failed
mingw32-make[2]: *** [ts] Error 127
mingw32-make[2]: *** Waiting for unfinished jobs....
mingw32-make[2]: Leaving directory 'E:/Software/C-CPP Windows GUI Programming/Qt/Plugins + Libs/LimeReport/build-limereport-Desktop_Qt_5_9_9_MinGW_32bit-Debug/limereport'
Makefile:36: recipe for target 'debug' failed
mingw32-make[1]: Leaving directory 'E:/Software/C-CPP Windows GUI Programming/Qt/Plugins + Libs/LimeReport/build-limereport-Desktop_Qt_5_9_9_MinGW_32bit-Debug/limereport'
mingw32-make[1]: *** [debug] Error 2
Makefile:89: recipe for target 'sub-limereport-make_first-ordered' failed
mingw32-make: *** [sub-limereport-make_first-ordered] Error 2
11:20:35: The process "I:\Programs\Qt\Qt5.9.9\Tools\mingw530_32\bin\mingw32-make.exe" exited with code 2.
Error while building/deploying project limereport (kit: Desktop Qt 5.9.9 MinGW 32bit)
When executing step "Make"
lupdate.exe is very much present inside the directory "I:\Programs\Qt\Qt5.9.9\5.9.9\mingw53_32\bin". The directory is part of PATH variable, and typing "lupdate" in cmd works.
Please tell me what is the problem and if I am doing anything wrong.
Note: I downloaded the source code from the official GitHub page and the source code compiles correctly in Linux. The Qt installation inside my Windows compiles all other programs correctly without any problem.

You are using a version of make that invokes a POSIX shell (/bin/sh), not the Windows cmd.exe shell.
In POSIX, backslashes are always escape characters and directories are separated by forward slashes (/) not backslashes.
Somewhere in your makefile you have set a variable to the path I:\Programs\Qt\Qt5.9.9\5.9.9\mingw53_32\bin\lupdate.exe or some part of that: replace the backslashes with forward slashes.
In general, in makefiles you should always use forward slashes as directory separators.

Okay, I used to following workaround to fix this problem:
I could not find any line in make file or pro file that had a mention of I:\Programs\Qt\Qt5.9.9\5.9.9\mingw53_32\bin\lupdate.exe. So, instead inside the limereport/limereport/limereport.pro file, I disabled the ts.commands = $$LUPDATE \"$$PWD\" -noobsolete -ts $$TRANSLATIONS line and qm.commands += $$LRELEASE -removeidentical $$tsfile -qm $$qmfile $$escape_expand(\\n\\t) line and it compiled correctly. I did not want any other-language translations, so I don't care about disabling the above line. This is not a permanent fix but definitely a workaround.

Related

Error using Cygwin: "collect2: fatal error: ld terminated with signal 11 [Segmentation fault]"

I'm trying to use cygwin to download openslide (building natively on Windows) on a Windows 10 x64 system. I ran into an error earlier relating to chk_fail and set the line in the build file with -D_FORTIFY_SOURCE to 0 instead of the default (2). You can probably tell by now I don't really know what I'm doing. But I got a new error below relating to a memory error from what I've read. I tried deleting the whole package folder including the makefiles and object files, then clone from Github again and rebuild, but it didn't work. Can anyone give me pointers about what's happening here and how to fix it? It would be much appreciated.
Scanning dependencies of target ziptool
[ 90%] Building C object src/CMakeFiles/ziptool.dir/ziptool.c.obj
[ 90%] Linking C executable ziptool.exe
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
make[2]: *** [src/CMakeFiles/ziptool.dir/build.make:109: src/ziptool.exe] Error 1
make[2]: *** Deleting file 'src/ziptool.exe'
make[1]: *** [CMakeFiles/Makefile2:442: src/CMakeFiles/ziptool.dir/all] Error 2
make: *** [Makefile:161: all] Error 2
Failed: make $parallel (line 417)
I solved this problem. Firstly, don't even bother to build this package using Cygwin. It won't work because of dependency issues and there is no record for version control in the package README.
For anyone else who has this problem like I did, you can download the latest versions of the code here: https://github.com/openslide/openslide-winbuild/releases and pick the latest one.
I first pip installed openslide-python. Then I moved openslide-win64-20171122 (from Github) into anaconda3/site-packages (not necessary, but nice), and then from anaconda3/site-packages/openslide I opened lowlevel.py.
In lowlevel.py, you need to add the following lines:
(in the beginning after importing libraries)
os.environ['PATH'] = "path/to/openslide-win64-20171122/bin" + ";" + os.environ['PATH']
You can also change this line:
if platform.system() == 'Windows':
_lib = cdll.LoadLibrary('libopenslide-0.dll')
to this:
if platform.system() == 'Windows':
_lib = cdll.LoadLibrary(util.find_library("libopenslide-0.dll"))
so that it searches for the libopenslide-0.dll file. Then don't forget to add from ctypes import util at the beginning.

Error when compiling Qt project. The process "/usr/bin/make" exited with code 2

I'm brand new to Qt and I tried to build a new project. I searched around and people seem to have similar problems but none of the solutions worked for me. I made New Project > Application > Qt widgets Application > created "Tester" file in /Volumes/MATT'S EHD/Qt > Kit: Desktop Qt 5.8.0 clang 64bit
I build it and this is my output:
sh: line 0: cd: /Volumes/MATTS\ EHD/Qt/build-Tester-Desktop_Qt_5_8_0_clang_64bit-Debug && /Volumes/MATT\S EHD/Qt/5.8/clang_64/bin/uic:
No such file or directory
/bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [main.o] Error 2
11:43:23: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project Tester (kit: Desktop Qt 5.8.0 clang 64bit)
When executing step "Make"
There's some other output but these are what's outputting in red and I'm assuming what's giving me issues. I haven't changed the file at all. I'm just trying to build it to see if it works and it doesn't. I'm running on OSX and everything is stored on my external hard drive. Any help is appreciated.
Since the error message complains about a missing matching (in that case closing) single quote, I strongly suspect your “MATT'S EHD” directory is a problem. That’s not too surprising because build systems in the C and C++ world are notoriously crappy when it comes to handling paths with spaces and/or quote characters.
Try a spaceless and quoteless path, not only for your project but also for your complete toolchain, especially the Qt installation. If you can’t or dont want to move your toolchain you can also try to backslash escape all special characters in Qt Creator’s “Build & Run” options. Should work theoretically, but I’ve never tried it in practice.

Error when build Ogre on Linux: narrowing conversion

I am trying to get Ogre on Linux. I downloaded the source files and uncompressed them. Then I created the build folder then I ran "cmake ..". After that completed, I ran "make -j4" (I do have 4 cores and I have also tried just make). I get to 49% and it stops every time. I have downloaded the cmake gui and ran configure and checked all the boxes. I hit configure again and then generate. I tried running "make" again.
Downloads/ogre_src_v1-8-1/RenderSystems/GL/src/atifs/src/ps_‌​1_4.cpp:689:1: error: narrowing conversion of ‘-35051’ from ‘int’ to ‘uint {aka unsigned int}’ inside { } [-Wnarrowing] };
That is the error that pops up several times except they refer to a different line of the code in ps_1_4.cpp and the number ‘-35051’ is different.
Also, There are several warnings for casting the const GLboolean* to GLboolean* throughout the build but this is the message that I have at the end:
RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/build.make:542: recipe for target 'RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/__/__/RenderSystem_GL/compile_RenderSystem_GL_0.cpp.o' failed
make[2]: *** [RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/__/__/RenderSystem_GL/compile_RenderSystem_GL_0.cpp.o] Error 1
CMakeFiles/Makefile2:1057: recipe for target 'RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/all' failed
make[1]: *** [RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
Also every time that I have tried a new way I delete the build folder and start all over. Each time it appears to end with this message. I am still relatively new to Linux and CMake, so can you explain what is going on and how you came to this conclusion?
Note: I have found one forum that talks about this but I don't know where the build function is or how to change the CXX_FLAG.
Referenced post suggests that Ogre can be successfully built using gnu++98 standard (which is actually a c++98 plus GNU extensions).
The standard is set via compiler flags, in case of cmake flags may be passed as:
cmake -DCMAKE_CXX_FLAGS="--std=gnu++98" ..

opencv_perf_stitching_Release.gch not generated by cmakefiles

I am trying to configure openCV with codeblocks but It got stuck during mingw32-make step, giving me this error:
[ 94%] Generating
perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch
C:/openCV/opencv/build/x86/mingw/modules/stitching/perf_precomp.hpp:1:0:
fatal error: can't creat e precompiled header
C:/opeCV/opencv/build/x86/mingw/modules/stitching/perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch:
No such file or directory #ifdef __GNUC__ ^ compilation terminated.
modules\stitching\CMakeFiles\pch_Generate_opencv_perf_stitching.dir\build.make:61:
recipe for tar get
'modules/stitching/perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch'
failed mingw32-make[2]: ***
[modules/stitching/perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch]
E rror 1 CMakeFiles\Makefile2:6569: recipe for target
'modules/stitching/CMakeFiles/pch_Generate_opencv_pe
rf_stitching.dir/all' failed mingw32-make[1]: ***
[modules/stitching/CMakeFiles/pch_Generate_opencv_perf_stitching.dir/all]
Er ror 2 Makefile:159: recipe for target 'all' failed mingw32-make:
*** [all] Error 2
I am unable to resolve it!
I am using windows 7 32bit
I met the similar problem that may be caused by cmd input limitation.
The cmd input limitation in win7 is about 8000 characters and in most case that is enough.
However in opencv build,one built component (opencv_perf_stitching_Release) might break this limition due to a long executed command.Because of different folder length for different users,the cutting point in executed command is located at unfixed position.Their error messages are also totally distinctive.In my example,I got a message unrecognized command line option '-sse' but i doubt we met the same problem.
The simplest solutiuon is to reduce your building folder level.In your case,you can change your install path from C:/opeCV/opencv/ to C:/opencv/ and try again.

GCC Cross-Compiler Cygwin64: GFDL license tm.texi

Following this tutorial: http://wiki.osdev.org/GCC_Cross-Compiler.
(I'm also using Cygwin64.)
When running "make install-gcc" i recieve the message:
Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc-4.9.0/gcc/doc/tm.texi.
Makefile:2227: recipe for target 's-tm-texi' failed
make[2]: *** [s-tm-texi] Error 1
make[2]: Leaving directory '/cygdrive/c/cygwin64/home/Demx/build/gcc'
Makefile:4038: recipe for target 'install-gcc' failed
make[1]: *** [install-gcc] Error 2
make[1]: Leaving directory '/cygdrive/c/cygwin64/home/Demx/build'
Makefile:2187: recipe for target 'install' failed
make: *** [install] Error 2
Where is this tm.texi and how do I verify that I have permission to grant a GFDL license? Or is there another root to the problem?
You shouldn't have to worry about anything if you're not modifying GCC; this looks like an FSF-copyright-related problem.
This looks like a timestamp-related problem in the build system. Sometimes generated files are shipped alongside their sources, and depending on which order they were (extracted from the tarball OR checked out from the repo) they may or may not be regenerated by 'make'.
(side note: I looked at the relevant Makefile, and it had special cases for both non-ASCII systems and for ASCII systems that didn't understand '\r')