I am building boost on my windows using mingw-4.8.1 and have a few targets which failed. My Problem is that, I do not know which specific targets failed and which were skipped.
Is there a way to list the failed/skipped targets after the build is completed?
Here the console output:
...failed updating 20 targets...
...skipped 28 targets...
...updated 5789 targets...
Commands used after downloading a unzipping boost:
bootstrap
once b2.exe is built. I execute the following command in cmd
b2 -j4 --build-dir=build toolset=gcc --build-type=complete --stagedir=C:\SW\Boost -sNO_BZIP2=1
System: Windows 7 ( intel i5 vPro)
Compiler: gcc (mingw 4.8.1)
Boost: boost 1.61.0
I had the same problem. After some research, I found this is the best way to see where it got failed.
My error messages (depends on your machine, you may see different ones):
...failed updating 6 targets...
...skipped 6 targets...
...updated 1092 targets...
I run ./b2 -q
This will stop at your first errors, in my case:
gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8.3/release/threading-multi/bzip2.o
libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory
#include "bzlib.h" // Julian Seward's "bzip.h" header.
^
compilation terminated.
"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8.3/release/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp"
...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8.3/release/threading-multi/bzip2.o...
...failed updating 1 target...
Then you can install the missing dependencies, and see your second missing ones.
To see every single one of your errors, you need to install dependencies on after
another. This is good, if you are determined to make a full boost build.
In my case, I compiled bzip library http://www.bzip.org/downloads.html.
This library is tricky to make. Boost needs the dynamic version on Linux.
make -f Makefile-libbz2_so
You have to manually copy the libbz2.so.1.0.6 file to /usr/local/lib
The make two symbolic links
libbz2.so.1 -> libbz2.so.1.0.6
libbz2.so -> libbz2.so.1
After this my boost can be made and I saw:
The Boost C++ Libraries were successfully built!
Or try ./b2 -s NO_BZIP2=1 to skip
So, a little bit of more research resulted in the following.
One can get the build configuration and other build output using
b2 [options]
b2 --help reveals the options that can be used. I used the following approaches to diagnose exactly which targets were failing or getting skipped.
Approach 1
As suggested by #JanHenke in comments, I ran the same command
b2 -j4 --build-dir=build toolset=gcc --build-type=complete --stagedir=C:\SW\Boost -sNO_BZIP2=1
(as mentioned in question) again.
Result: All tragets that are already built are skipped and only failed ones are shown.
Problem: If there are many targets which failed then this just floods the console and it is difficult to find out what is going on.
Approach 2
Run the command (see 1) and select all from the command prompt using right mouse click, and then click gain to copy and paste it in a text editor so that is searchable.
Result: Usable insights can be drawn by searching for failed or error keywords
Problem: Still not the optimal way as not all the info is vailable on the current cmd window.
Approach 3
Not Done as for me 2. worked, but should surely work
Create a batchfile where in, the command is written and all that is printed on the cmd window, gets logged in a text file using the > or >> operators.
Result: Will be the best way (known to me till now) to know which exact targets are getting failed and a proper diagnostic action can be taken.
PS: I found that the there is a bug when trying to build serialization library with MinGW. Below the error I am facing and a link to boost forum which talks about the same error.
gcc.compile.c++ build\boost\bin.v2\libs\serialization\build\gcc-mingw-4.8.1\debug\xml_woarchive.o
In file included from ./boost/archive/detail/utf8_codecvt_facet.hpp:23:0,
from ./boost/archive/impl/xml_woarchive_impl.ipp:34,
from libs\serialization\src\xml_woarchive.cpp:28:
./boost/detail/utf8_codecvt_facet.hpp:116:30: error:
function 'boost::archive::detail::utf8_codecvt_facet::utf8_codecvt_facet(std::size_t)'
definition is marked dllimport
More info Reference1 and Reference2.
Sadly have not found a solution for it yet. Also, it is not the scope of this question.
Related
I want to run MinGW as a C compiler. MinGW has been installed from Chocolatey. Invocation is from gitlab-runner through CMake. This fails with
$ cmake -G "MinGW Makefiles" -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DLIB_MAN=OFF -DCMAKE_INSTALL_PREFIX=C:\opt\x64 -B. ..
-- The C compiler identification is unknown
-- Check for working C compiler: C:/ProgramData/chocolatey/bin/x86_64-w64-mingw32-gcc.exe
-- Check for working C compiler: C:/ProgramData/chocolatey/bin/x86_64-w64-mingw32-gcc.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"C:/ProgramData/chocolatey/bin/x86_64-w64-mingw32-gcc.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/ProgramData/chocolatey/bin/mingw32-make.exe cmTC_ffa53/fast && C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/mingw32-make -f CMakeFiles\cmTC_ffa53.dir\build.make CMakeFiles/cmTC_ffa53.dir/build
mingw32-make[1]: Entering directory 'C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_ffa53.dir/testCCompiler.c.obj
C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-gcc.exe -o CMakeFiles\cmTC_ffa53.dir\testCCompiler.c.obj -c C:\gitlab-runner\builds\zjE1Mkfg\0\mlz\kww\build\CMakeFiles\CMakeTmp\testCCompiler.c
mingw32-make[1]: *** [CMakeFiles\cmTC_ffa53.dir\build.make:65: CMakeFiles/cmTC_ffa53.dir/testCCompiler.c.obj] Error 1
mingw32-make[1]: Leaving directory 'C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeTmp'
mingw32-make: *** [Makefile:120: cmTC_ffa53/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:6 (project)
-- Configuring incomplete, errors occurred!
See also "C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeOutput.log".
See also "C:/gitlab-runner/builds/zjE1Mkfg/0/mlz/kww/build/CMakeFiles/CMakeError.log".
ERROR: Job failed: exit status 1
From various web sources I understand that MinGW is bound to fail if sh.exe is present on the system [1]. However, sh.exe comes with several applications, among them Git and Visual Studio, which I cannot remove. Somewhere it's suggested to add -DCMAKE_SH="CMAKE_SH-NOTFOUND", which, however, has no effect.
I've seen a related question from 2015 [2], which however involves CLion. The only upvoted answer contains several broken links - altogether, that thread isn't helpful.
How to proceed? Is there a chance to work around the sh.exe problem?
Other advice on the web suggests to use -G "MSYS Makefiles". However, the CMake documentation [3] seems to rule this out: "not compatible with a Windows command prompt. To build under a Windows command prompt, use the MinGW Makefiles generator."
[1] https://stackoverflow.com/a/7411982/1017348
[2] CLion: Error:The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple test program
[3] https://cmake.org/cmake/help/latest/generator/MSYS%20Makefiles.html#generator:MSYS%20Makefiles per CMake 3.16.1
After long experimentation, I conclude that the problem comes from Chocolatey's packaging of MinGW. The problem is gone after I
uninstalled the MinGW package from Chocolatey,
reinstalled MinGW using the original MinGW installer,
installed the Ninja Chocolatey package,
inserted C:\MinGW\bin on top of PATH.
$ cmake -G "Ninja" -DLIB_MAN=OFF -DCMAKE_INSTALL_PREFIX=C:\opt\x64 -B. ..
-- The C compiler identification is GNU 8.2.0
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- works
Also note:
There is no need for -DCMAKE_C_COMPILER=...
I did not try hard to get -G "MinGW Makefile" working; -G Ninja works just fine.
The sh.exe is only a problem when you run CMake the first time when trying to generate the project. You can rerun CMake again and CMake will continue with normal processing to generate the project (tested in version 3.16). I saw a patch that removes this check and should be part of a future release of CMake.
It's already mentioned that gcc is installed incorrectly. That always seems to be the case when anyone mentions that gcc fails with an Error 1 message. It should be noted that Error 1 is not from CMake. CMake is just gathering the output from when it runs mingw32-make to build the sample project.
The first message in the output -- The C compiler identification is unknown is a pretty clear message that your compiler isn't working. All of the output for this step is in the log and error files that CMake generates in the build folder. You'll be able to see how it invoked the compiler and with which options and the output from the compiler.
I am trying to cross-compile the Azure IoT SDK C for a Mips processor. Cross-compiling an older version of the same SDK using an older version of CMake (2.8.12.2) works just fine, so I doubt it's the code itself. I am guessing it's the Mips GCC compiler.
Error message:
CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_2cc84/fast"
/usr/bin/make -f CMakeFiles/cmTC_2cc84.dir/build.make CMakeFiles/cmTC_2cc84.dir/build
make[1]: Entering directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -o CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -c /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_2cc84
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_2cc84.dir/link.txt --verbose=1
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -rdynamic CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -o cmTC_2cc84
/usr/local/mipsisa32r2el/r23/lib/gcc/mipsisa32r2el-axis-linux-gnu/4.7.2/../../../../mipsisa32r2el-axis-linux-gnu/bin/ld: this linker was not configured to use sysroots
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_2cc84.dir/build.make:97: recipe for target 'cmTC_2cc84' failed
make[1]: *** [cmTC_2cc84] Error 1
make[1]: Leaving directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_2cc84/fast' failed
make: *** [cmTC_2cc84/fast] Error 2
Unfortunately, I am stuck with the Mips GCC compiler I have. Is there a way to disable this test-program check?
Solution was to add these to the toolchain-file:
SET (CMAKE_C_COMPILER_WORKS 1)
SET (CMAKE_CXX_COMPILER_WORKS 1)
CMake tries to compile an executable using "standard" (as per what CMake thinks is standard) compiler options and tries to run that executable, so to see if the compiler is working. The executable is simple like int main(int argc, char *argv[]) { return argc - 1; }.
You can't do that when cross-compiling. Because usually you can't link with a proper C standard library, you don't have printf, or _start or _exit or similar, passing arguments to main is implementation-defined, or you need a special linker script, or there's no emulator for your architecture, so can't run cross-compiled source on the host, etc... Simply: you usually can't run the cross-compiled executable on the host, and most of the time even the compilation is hard enough to do.
The common solution is to set before project():
set(CMAKE_TRY_COMPILE_TARGET_TYPE "STATIC_LIBRARY")
So that CMake will try to compile a static library not an executable, as explained in cmake docs CMAKE_TRY_COMPILE_TARGET_TYPE. This avoids running the linker and is intended for cross-compiling.
You can set CMAKE_C_COMPILER_WORKS and it will omit the check in CMakeTestCCompiler.cmake, but CMAKE_TRY_COMPILE_TARGET_TYPE is a more proper solution.
Well this problem is really annoying, i faced this issue for 2 day now I got solution.
Let me explain my issue first
When I delete NDK and Cmake from Sdk folder and Run my application then grable install NDK and Cmake again.
Only that time Application run and when try to run again i get this error The C Compiler is not able to compile a simple test program.
Before i was using ndkVersion "22.0.7026061" then change to thisndkVersion "21.1.6352462" and IT WORKED.
I think this is NDK problem and most of answer are outdated try this i hope this will HELP.
If using CMake GUI, you can add a boolean entry named
CMAKE_CXX_COMPILER_FORCED
then set it to True.
This will skip checking process for this build.
Ran into the same problem while re-compiling a project. Turned out that the compiler had been updated in the meantime.
After removing the build directory and creating it again, the compilation completed without errors.
I am attempting to build an application using g++ that is composed of several source files and also uses OpenCV 3.1.0.
The CMD command is:
g++ -o home_surveillance -static -std=c++11 -m64 -IC:\Tools\OpenCV\opencv\build\include -LC:\Tools\OpenCV\opencv\build\x64\vc14\lib -lopencv_world310 configuration_manager.cpp events.cpp image_processor.cpp main.cpp response_module.cpp scheduler.cpp
The error produced is:
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopencv_world310
collect2.exe: error: ld returned 1 exit status
I have been trying various things and searching for answers for a couple days now. I should note that the application builds properly in Visual Studio 2015. I have tried compiling the source files using g++ with the -c option and they all seem to compile fine. It is just the linking phase that produces an error.
Things I have tried:
Just about every possible combination of the specified command. (Modifying order of the options, -lopencv_world310.a, -lopencv_world310.lib, -lopencv_world310, -l"full_path"+"opencv_world310", etc..)
Checked that all the paths and filenames are correct.
Reinstalled mingw to make sure I was using mingw-w64 since this is a 64-bit application.
Running CMD as admin thinking maybe CMD could not access the path specified with -L option.
Googling and reading every post I could find. (Most posts about "ld.exe cannot find "library_name" are a result of someone using "library_name".a or "library_name".lib as input to the -l option).
Reading mingw documentation on the use of GCC/g++ to ensure I wasn't missing anything obvious.
Praying to Bjarne Stroustrup.
Ritual sacrifice involving a Pentium 2.
I am using Windows 7 64-bit, and want to compile the non-precompiled libraries (specifically, I need Filesystem) from the command line (I do not use MSVC). I have MinGW, but read on the Boost website that MSYS shell is not supported, so I'm trying to compile the libraries from the Windows command prompt.
First of all, running bootstrap.bat results in the following error:
Building Boost.Jam build engine
'cl' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Jam build engine.
Please consult bjam.log for furter diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bjam.log in that case.
Plus, there is not bjam.log file anywhere in the boost_root directory.
Disregarding this error, and trying to run the downloaded bjam.exe file, I get another error:
c:/boost_1_45_0/tools/build/v2/build\configure.jam:145: in builds-raw
*** argument error
* rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? )
* called with: ( <pbin.v2\libs\regex\build\gcc-mingw-4.5.2\debug\address-model64\architecture-x86>has_icu.exe : : ignore-minus-n : ignore-minus-q )
* extra argument ignore-minus-q
(builtin):see definition of rule 'UPDATE_NOW' being called
c:/boost_1_45_0/tools/build/v2/build\configure.jam:179: in configu
re.builds
c:/boost_1_45_0/tools/build/v2/build\configure.jam:216: in object(
check-target-builds-worker)#409.check
etc. with quite a lot of complaints. Setting the 'architecture' and 'address-model' options doesn't help.
Any suggestions?
#Andre
Following Andre's suggestion, I created minGW-bjam that was running for an hour and a half and built most of the libraries, but not the one I need at this moment: Filesystem.
Trying to compile only Filesystem, specifying version 2 with define="BOOST_FILESYSTEM_VERSION=2" and --disable-filesystem3 does not help. I get the following error:
gcc.compile.c++ bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o
In file included from ./boost/filesystem/v3/operations.hpp:24:0,
from libs\filesystem\v3\src\operations.cpp:48:
./boost/filesystem/v3/config.hpp:16:5: error: #error Compiling Filesystem version 3
file with BOOST_FILESYSTEM_VERSION defined != 3
libs\filesystem\v3\src\operations.cpp:647:26: warning:
'<unnamed>::create_symbolic_link_api' defined but not used
"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -
DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_SYSTEM_DYN_LINK=1 -
I"." -c -o "bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o"
"libs\filesystem\v3\src\operations.cpp"
etc. with a lot of ...failed statements.
Any hints here?
It's easy. Just use "bootstrap.bat gcc" to select GCC
The bootstrap script assumes the msvc compiler is available. But you can build bjam by hand without the bootstrap script:
Step into the tools\build\v2\engine\src directory and call "build.bat mingw". It will create a bjam.exe. You can then put it in your %PATH% or perhaps in the root boost directory...
To be honest, I usually build bjam like this with the msvc compiler and use this "msvc-bjam" to build my mingw boost libraries.
So... the first part of the problem was solved by Andre's suggestion.
The second part was solved by setting the variable BOOST_FILESYSTEM_VERSION to 3 everywhere (the error above complains about incompatibility with what is set in file user.hpp). Although this is not the default option for Boost 1.45 that I'm using, it's the only thing that works (i.e. bjam wants to compile version 3 no matter what). So now I have version 3 of the filesystem library, and version 2 for all others, but that doesn't seem to be an issue for the moment.
I do have a problem with using Boost with OpenCV and Eigen libraries, though... off to the next challenge ;)
Since I can't comment yet, I want to add that I ran
bootstrap mingw
to generate b2 properly and then
b2 --build-dir="c:\boost_release" toolset=gcc --build-type=complete "c:\boost_release\stage"
The includes will be located at your boost root folder (boost_1_58_00/boost) and your binaries at the specified build folder.
I want to build "gcc cross-compiler" to compile "c/c++" applications on "Linux" environment but for "Windows" target.
I have made this so far:
Installed the necessary tools and packages for building GCC listed on "Prerequisites for GCC" page.
Downloaded required sources:
"gcc-core-4.4.1", "gcc-g++-4.4.1", "binutils-2.19.1", "w32api-3.13-mingw32", "mingwrt-3.16-mingw32"
Created this directory hierarchy:
"${HOME}/gcc/" - for final cross-compiler
"${HOME}/src/" - for sources
"${HOME}/src/build-binutils/i386-mingw32/" - for building binutils to "i386-mingw32" target
"${HOME}/src/build-gcc/i386-mingw32/" - for building gcc to "i386-mingw32" target
Builded binutils package:
cd "${HOME}/src/build-binutils/i386-mingw32/"
../../binutils-2.19.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --disable-nls
make
make install
Copied "w32api" and "mingwrt" headers to the install directory:
cp -R "${HOME}/src/w32api-3.13-mingw32/include" "${HOME}/gcc/i386-mingw32"
cp -R "${HOME}/src/mingwrt-3.16-mingw32/include" "${HOME}/gcc/i386-mingw32"
And now when I am trying to build the "c (only) cross-compiler":
cd "${HOME}/src/build-gcc/i386-mingw32/"
../../gcc-4.4.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --enable-languages=c --with-headers="${HOME}/gcc/i386-mingw32/include" --disable-nls
make<br>
it was building something about 4 minutes and then gives me these errors:
${HOME}/gcc/i386-mingw32/bin/ld: dllcrt2.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dll] Error 1
make[2]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32/i386-mingw32/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32'
make: *** [all] Error 2
From that error message I really don't know what to do now :-((( .
Does anybody know where is the problem?
Thanks.
That's actually OK: the way things go, you need to
build binutils
install headers
build the a partial C compiler: enough to create object files, but not enough to link
build the win32api and mingw runtime (which includes your missing dllcrt2.o)
build a complete C compiler (and other front-ends, such as C++, Fortran, Ada, whatever, if you want them)
You have successful performed step 3 above; it fails building libgcc (which is a GCC support library), but that means the C compiler core is functionnal (although it won't be able to link, it can still create valid object files). You can check that by looking at the gcc/xgcc file in your GCC build directory.
So, you need to go to the next step, not worrying about your current failure.
(To actuall install the partial C compiler, you should run make with the -k option, to have it do it best, even in the face of errors. For example, use make -k install.)
There are precompiled cross-compilers of MinGW-w64 available.
This allows to compile native 32- and 64-bit Windows binaries from Linux, a two minute tutorial is available at http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/
Just in case you don't want to spend a lot of time trying to build it yourself.
I grepped through the MinGW sources, and found that dllcrt2.o is something built off the mingwrt package. I assume you have to compile and install that, not just copy the headers?