I used to use MSVC a lot, and now I want to try out new C++17 features, so I decided to use mingw-w64 toolchian.
Btw I'm new to building things from source
I also want the ability to compile both 32 bit and 64 bit application (multilib).
I had mingw-w64 headers installed, then I tried to bootstrap GCC 7.1.0 in MSYS2.
I configured it by this command
../src/configure --enable-languages=c,c++ --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --enable-targets=all --disable-werror --prefix=/c/tmp/gcc/dest --with-sysroot=/c/tmp/gcc/dest --disable-shared --disable-win32-registry --enable-version-specific-runtime-libs
The process completed without an error, however the compiler isn't usable.
I tried to compile a file a.cpp by
g++ -o a.exe a.cpp
Unfortunately, a message box with title cc1plus appeared saying The code execution cannot proceed because libgcc_s_seh-1.dll was not found.
Reinstalling the program may fix this problem.
That suggested that I should have libgcc, but how can I get it?
Related
I'm on a CentOS 7 Linux system where I don't have the root access. So I have to build gcc from source. I want to build gcc 11.2 with the jit support. I invoked
contrib/download_prerequisites for GMP, MPFR, MPC and ISL. Then from a build directory I configured gcc using
../gcc-11.2.0/configure --prefix=/some/path --enable-bootstrap --enable-shared \
--enable-host-shared --enable-threads=posix --enable-languages=c,c++,jit \
--disable-multilib
then I hit make.
It failed with ld errors asking me to recompile libisl.a, libmpc.a, libmpfr.a, libgmp.a with -fPIC. Right before these errors I saw lots of jit related outputs. I assume jit is behind all of this?
Then I tried adding CFLAGS=-fPIC to the above configure command as ../gcc-11.2.0/configure CFLAGS=-fPIC *rest_of_the_options_above*. The same ld errors were emitted.
I'm aware that those dependencies each has --with-pic option to their own configure. But I'm wondering if there is a way to have gcc invoke that for me? If not, does it mean that to build gcc with jit support, one has to build the four dependencies manually with --with-pic? Thanks.
I'm currently building Binutils 2.32 for the armv7l-unknown-linux-gnueabihf target, with this configure command:
chronos#localhost ~/Downloads/tarballs/binutils-2.32 $ ./configure --prefix=/usr/local/opt/arm-cross --target=armv7l-unknown-linux-gnueabihf --enable-shared --enable-host-shared --disable-static --enable-plugins --enable-gold=default --enable-ld --with-system-zlib
I ran make -j3 && make install, and no errors occured.
However, when I added /usr/local/opt/arm-cross/bin to my path and ran armv7l-unknown-linux-gnueabihf-objdump, this error occured:
armv7l-unknown-linux-gnueabihf-objdump: can't set BFD default target to `armv7l-unknown-linux-gnueabihf': invalid bfd target
How do I fix this? I searched on Stack Overflow and Google and couldn't come up with anything.
You configured with --enable-shared --enable-host-shared --disable-static. This means that it is you need to make sure that the binutils programs can find the shared objects they need. Therefore, in addition to PATH, you have to use LD_LIBRARY_PATH, or otherwise make the BFD library available to your custom binutils build.
This could however affect how other installed binutils versions find their BFD library, so it may be easier to link your version statically.
I have a setup with Windows 7, MSYS2, Mingw-w64-x86_64 gcc toolchain, CMake, and I am trying to build the nanomsg library.
Here is what I obtain :
$ cmake --debug-trycompile
-DCMAKE_TOOLCHAIN_FILE=../toolchain_i686-pc-mingw32.cmake -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32 -G "MinGW Makefiles" ../nanomsg
debug trycompile on
-- The C compiler identification is GNU 4.8.2
-- Check for working C compiler: C:/mingw64/bin/x86_64-w64-mingw32-gcc.exe
-- Check for working C compiler: C:/mingw64/bin/x86_64-w64-mingw32-gcc.exe -- broken CMake Error at
C:/cmake-win32-x86/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61
(message): The C compiler
"C:/mingw64/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:/msys64/home/Laurent/Dev/nanomsg-build/CMakeFiles/CMakeTmp
Run Build Command:C:/mingw64/bin/mingw32-make.exe
"cmTryCompileExec910276652/fast"
C:/mingw64/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec910276652.dir\build.make
CMakeFiles/cmTryCompileExec910276652.dir/build
mingw32-make.exe1: Entering directory
'C:/msys64/home/Laurent/Dev/nanomsg-build/CMakeFiles/CMakeTmp'
C:\cmake-win32-x86\bin\cmake.exe -E cmake_progress_report
C:\msys64\home\Laurent\Dev\nanomsg-build\CMakeFiles\CMakeTmp\CMakeFiles
1
Building C object
CMakeFiles/cmTryCompileExec910276652.dir/testCCompiler.c.obj
C:\mingw64\bin\x86_64-w64-mingw32-gcc.exe -o
CMakeFiles\cmTryCompileExec910276652.dir\testCCompiler.c.obj -c
C:\msys64\home\Laurent\Dev\nanomsg-build\CMakeFiles\CMakeTmp\testCCompiler.c
Linking C executable cmTryCompileExec910276652.exe
C:\cmake-win32-x86\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec910276652.dir\link.txt --verbose=1
C:\cmake-win32-x86\bin\cmake.exe -E remove -f
CMakeFiles\cmTryCompileExec910276652.dir/objects.a
x86_64-w64-mingw32-gcc-ar cr
CMakeFiles\cmTryCompileExec910276652.dir/objects.a
#CMakeFiles\cmTryCompileExec910276652.dir\objects1.rsp
sorry - this program has been built without plugin support
CMakeFiles\cmTryCompileExec910276652.dir\build.make:91: recipe for
target 'cmTryCompileExec910276652.exe' failed
mingw32-make.exe1: * [cmTryCompileExec910276652.exe] Error 1
mingw32-make.exe1: Leaving directory
'C:/msys64/home/Laurent/Dev/nanomsg-build/CMakeFiles/CMakeTmp'
Makefile:116: recipe for target 'cmTryCompileExec910276652/fast'
failed
mingw32-make.exe: * [cmTryCompileExec910276652/fast] Error 2
CMake will not be able to correctly generate this project. Call
Stack (most recent call first): CMakeLists.txt:29 (project)
Here is my toolchain file:
$ cat ../toolchain_i686-pc-mingw32.cmake
# http://www.cmake.org/Wiki/CMake_Cross_Compiling#The_toolchain_file
# http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=8959
# http://stackoverflow.com/questions/19754316/cross-compiling-opencv-with-mingw-using-cmakein-linux-for-windows
# this one is important
SET(CMAKE_SYSTEM_NAME Windows)
#this one not so much
#SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
SET(PREFIX x86_64-w64-mingw32)
SET(CMAKE_MAKE_PROGRAM mingw32-make)
SET(CMAKE_C_COMPILER ${PREFIX}-gcc)
SET(CMAKE_CXX_COMPILER ${PREFIX}-g++)
SET(CMAKE_AR ${PREFIX}-gcc-ar)
SET(CMAKE_NM ${PREFIX}-gcc-nm)
SET(CMAKE_RC_COMPILER windres)
# specify the cross linker
SET(CMAKE_RANLIB ${PREFIX}-gcc-ranlib)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH /opt/mingw64 /usr/${PREFIX})
# search for programs in the build host directories
#SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
#SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
#SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
It looks like it fails to build on an auto test because the toolchain misses plugin support.
Here is my gcc version and options:
$ /opt/mingw64/bin/x86_64-w64-mingw32-gcc.exe -v
Using built-in specs.
COLLECT_GCC=C:\mingw64\bin\x86_64-w64-mingw32-gcc.exe
COLLECT_LTO_WRAPPER=C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.2/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-cloog=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='x86_64-posix-seh-rev3, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64/opt/include -I/c/mingw482/prerequisites/x86_64-zlib-static/include -I/c/mingw482/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64/opt/include -I/c/mingw482/prerequisites/x86_64-zlib-static/include -I/c/mingw482/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64/opt/lib -L/c/mingw482/prerequisites/x86_64-zlib-static/lib -L/c/mingw482/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 4.8.2 (x86_64-posix-seh-rev3, Built by MinGW-W64 project)
Is it related to the "--enable-plugin" option (missing in my gcc) ?
Is there somewhere a toolchain build available with this option set ? I looked for it in MSYS2, Mingw-w64, rubenvb repositories, but it is not there. Or shall I build it myself ?
Possibly nanomsg does not need it ? Does the autotest requires it because nanomsg needs it ? Or can I prevent this autotest from being run ? Or can I set something to avoid the need of the "--enable-plugins" option ?
I think you are using the MSYS2 shell here, and not MSYS2 itself. If you were using an up to date MSYS2 then you'd be using the following mingw-w64 x86_64 GCC:
$ pacman -Ss mingw-w64-x86_64-gcc
mingw64/mingw-w64-x86_64-gcc 4.9.1-6
$ PATH=/mingw64/bin:$PATH gcc -v
Configured with: ... --enable-lto ...
--enable-lto implies --enable-plugins which is the default now and so doesn't appear in the list.
To build nanomsg with MSYS2, install https://master-dl.sourceforge.net/project/msys2/Base/x86_64/msys2-x86_64-20141003.exe, untick "Run MSYS2 shell now" (you want a mingw-w64 shell instead). Run the mingw-w64 shell (Start->MSYS2 64Bit->MinGW-w64 Win64 Shell). From within that shell:
$ pacman -S git make mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc
$ git clone https://github.com/nanomsg/nanomsg.git
$ mkdir nanomsg-build
$ cd nanomsg-build
$ cmake --debug-trycompile -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32 -G "MSYS Makefiles" ../nanomsg
$ make install
But if you are a developer, we'd appreciate the contribution of a PKGBUILD for nanomsg
I'm using MinGW-w64 with POSIX threads. I want to build GNU gettext with POSIX threads and as shared libraries (DLLs in this case). However, when one builds runtime artifacts (such as DLLs or executables) which depend on POSIX threads with MinGW/MinGW-w64, one ends up with these artifacts being dependent on libwinpthread-1.dll. In my case, I want to avoid that and link any runtime artifacts against POSIX threads statically! The only way one can do that on MinGW/MinGW-w64 is to supply -static flag during the linkage stage. I've done that hundreds of times before, so I know that it works.
The problem now is that I have to deal with notorious Autotools which have just proven yet again that they are absolutely inflexible, unfriendly, and cumbersome to use. So there we go:
LDFLAGS="-static-libgcc -static-libstdc++ -static" ../configure --build=x86_64-w64-mingw32 --disable-static --enable-shared --disable-java --disable-native-java --enable-relocatable --enable-threads=posix --prefix=<prefix>
Guess what? This guy somehow parses that I've added -static and it does the following to my build:
All the GNU gettext libraries that should have been built as DLLs (due to --enable-shared and --disable-static) are now built as static libraries/archives;
All the GNU gettext executables are built with -static excluded what makes them dependent on libwinpthread-1.dll, for instance:
gcc -pipe -Wall -Wextra -O3 -static-libgcc -static-libstdc++ -o test-lock.exe test-lock.o lock.o threadlib.o -lpthread
as we can see Autotools have intentionally filtered out only the -static without my permission and any logical reason to do so.
I tried various things, and even found:
link_static_flag="-static"
in the libtool file. I've tried to change it to:
link_static_flag=""
in hope that it will prevent libtool from reacting like that when the -static flag is present. Unfortunately, no success yet. This is incredibly frustrating.
OK, Autotools gurus, now it's finally your time to shine.
I configured gcc as follows:
../configure
--prefix=/c/mbuild/release --enable-shared=libstdc++ --enable-threads --enable-version-specific-runtime-libs --enable-languages=c,c++ --with-dwarf2 --disable-sjlj-exceptions --disable-win32-registry --disable-werror --disable-nls --disable-multilib --with-gmp=/c/mbuild/release --with-ppl=/c/mbuild/release --disable-ppl-version-check --with-cloog=/c/mbuild/release --disable-cloog-version-check --with-mpfr=/c/mbuild/release --with-mpc=/c/mbuild/release --enable-libgomp --with-libiconv-prefix=/c/mbuild/release
--enable-libstdcxx-debug --enable-cxx-flags='-s -O2' *--with-boot-ldflags='-s'* --with-boot-cflags='-s -O2' --with-boot-cxxflags='-s -O2' &>config.my.log
and build:
make -j4 BOOT_CFLAGS='-s -O2'
BOOT_CPPFLAGS='-s -O2' &>make.my.log
I've got everything optimized, except libstdc++-6.dll. It size is 5Mb!
So... What options should i use during gcc (mingw) configuration to build libstdc++.dll without debugging information?
NOTE:
I need debug and release versions of libstdc++, so I'm using
--enable-libstdcxx-debug - Build separate debug libraries in addition to what is normally built.
This flag makes another libstdc++-6.dll (somwhere in lib dir), wich is larger, than dll in the bin dir.
You should pass strip option to linker, not to compiler (-s). And to compiler you should pass "-g -O0" for debug build, which means include debug information + stright code generation without any optimization (the last one is for case you read disasm code, it makes stuff clearer). So, try adding to LDFLAGS environment variable -s option for build time.
As an alternative, you could use "strip" program (part of MSYS) to strip all debug info from executable and/or library binary file.