configure fails with "C compiler cannot create executables" - gcc

Right now I'm trying to compile the google protocol buffers from source with MinGW but when I try:
Matthew#RaRemoz-8 /e/workspace/protobuf-2.5.0
$ ./configure
checking whether to enable maintainer-specific portions of Makefiles... yes
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/e/workspace/protobuf-2.5.0':
configure: error: C compiler cannot create executables
See `config.log' for more details
and the config says: This
it seems to fail around this
configure:3474: checking whether the C compiler works
configure:3496: gcc conftest.c >&5
gcc.exe: error: CreateProcess: No such file or directory
configure:3500: $? = 1
configure:3538: result: no
heres the output of -v:
$ gcc -v helloworld.c
Using built-in specs.
COLLECT_GCC=E:\MinGW\bin\gcc.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro'
cc1 -quiet -v -iprefix E:\MinGWmingw32/4.8.1/ helloworld.c -quiet -dumpbase hel
loworld.c -mtune=generic -march=pentiumpro -auxbase helloworld -version -o C:\Us
ers\Matthew\AppData\Local\Temp\ccVVxhTh.s
gcc.exe: error: CreateProcess: No such file or directory
anyone encountered this or can help with this?

There's something wrong with your MinGW install, or maybe it's just that your PATH environment variable isn't set up quite right.
COLLECT_GCC indicates that gcc is in E:\MinGW\bin\gcc.exe
COLLECT_GCC_OPTIONS indicates that gcc couldn't locate cc1.exe, so it's trying to execute it as a simple cc1 command hoping that the system will find it by a normal PATH search. The system doesn't find it, so you get the CreateProcess error. Because the Target that GCC is built for is mingw32, I'd expect that cc1.exe would be located in E:\MinGW\libexec\gcc\mingw32\4.8.1\cc1.exe.
There's something else interesting about the cc1 invocation: it specifies the option -iprefix E:\MinGWmingw32/4.8.1/.
I'd expect it to look like: -iprefix E:\MinGW\bin\../lib/gcc/mingw32/4.8.1/
Something is munging the -iprefix option, but I'm not sure what.
I'd suggest reinstalling MinGW. As mentioned in one of my comments, I'd choose one of the following distributions since they've always installed in a straightforward manner for me. I can't say the same thing for the standard MinGW distribution installer, though I hear it's been greatly improved over the past few years.
nuwen.net's MinGW Distro - note that recent versions of this are 64-bit native, so it will only run on 64-bit machines and apparently will only build 64-bit binaries (distro versions before 11.0 were 32-bit native and only built 32-bit binaries). One very nice thing about nuwen MinGW is that installation is simply unpacking the archive and setting the path appropriately. There's a set_distro_paths.bat that will add it to the path for you. Nuwen's distribution also includes several libraries, including Boost. Unfortunately C++11 threads don't seem to be supported just yet.
TDM MinGW - you have a choice of 32-bit or 64-bit versions. The 64-bit version will build either 32 or 64-bit targets. The toolchain itself is a 32-bit build, so it doesn't need a 64-bit machine to perform the compile/link steps. Use the -m32 option to build a 32-bit target. The installer for TDM is a wizard-style installer. C++ 11 threads are supported, but Boost isn't included.

Related

problems when configure omnet (omnetpp-5.4.1)

I have run into probelms when configure omnetpp-5.1.1 on windows10
I have installed gcc sucessfully as showed below:
PS C:\Users\admin> gcc -v
specs
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
mingw32
../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
win32
gcc 6.3.0 (MinGW.org GCC-6.3.0-1)
2.when I follow the instructions and Type "./configure"
the problem ouccurs: here is my log
/d/softwares/omnet/omnetpp/omnetpp-5.4.1$ ./configure
configure: loading site script /mingw64/etc/config.site
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
configure: -----------------------------------------------
configure: reading configure.user for your custom settings
configure: -----------------------------------------------
checking for clang... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ISO C89... none needed
checking for clang++... clang++
checking whether we are using the GNU C++ compiler... yes
checking whether clang++ accepts -g... yes
checking for clang++... clang++
checking for ranlib... ranlib
checking whether clang++ supports -fno-stack-protector... yes
checking whether clang++ supports -Wl,--no-as-needed... yes
checking whether clang++ supports -Wl,--as-needed... yes
checking for swapcontext... no
checking if shared libs need -fPIC... no
checking for dlopen with CFLAGS="" LIBS=""... no
checking if --export-dynamic linker option is supported/needed... test failed
checking for flags needed to link with static libs containing simple modules... --whole-archive
configure: NOTE: Use the following syntax when linking with static libraries
configure: containing simple modules and other dynamically registered components:
configure: clang++ ... -Wl,--whole-archive <libs> -Wl,--no-whole-archive ...
checking whether linker supports -rpath... yes
checking for bison... bison -y
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... none needed
checking whether yytext is a pointer... no
checking for make... make
checking for perl... perl
checking for swig... not found
checking for math with CFLAGS="" LIBS=""... yes
**checking for standard C++ lib with CFLAGS="" LIBS="-lstdc++"... no
checking for standard C++ lib with CFLAGS="" LIBS="-lc++"... no
checking for standard C++ lib with CFLAGS="" LIBS="-lcxa"... no**
configure: error: Standard C++ library -lstdc++_s or -lstdc++ or -lcxx or -lcxa or -lc++ not found
# here is the probelm
It always shows the probelms missing C++ lib, but I don't know if it's the broken lib's problem. If so, what should I do to fix this problem.
Please help me. Thanks a lot!
OMNeT++ for Windows does not require installing external GCC from MinGW. All necessary tools and libraries are already present in the ZIP package.
Make sure that real-time protection in your antivirus is turned off during calling ./configure and make.

configure: error: cannot run C compiled programs. when installing libtools-2.4.2

Have been struggling to set up my environment to run bioinformatics tools. The issue started with a consistent autogen.sh error in autoreconf -fi: command not found for multiple applications. Reinstalled autoconf, automake, libtools.
Currently, libtools installation fails at ./configure, but autoconf and automake installed successfully.
Here is the error:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... libltdl/config/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-apple-darwin18.0.0
checking host system type... x86_64-apple-darwin18.0.0
configure: autobuild project... GNU Libtool
configure: autobuild revision... 2.4.2 ()
configure: autobuild hostname... MACUSR
configure: autobuild mode... default
configure: autobuild timestamp... 2019011
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/usr/local/libtool-2.4.2':
configure: error: cannot run C compiled programs.
Tried Homebrew, it installed all my tools in usr/local/Cellar and nothing runs, I have added tool locations to my PATH variable, but no luck. Traced problem to jamf issue:
https://www.jamf.com/jamf-nation/discussions/28764/jamf-quickadd-symlinks-usr-local-bin-causing-install-problems-for-other-apps
Stuck and will be happy for an advice here.
Long story short, it was an old gcc problem. My PATH referenced to anaconda3/bin first, where it was triggering whatever gcc it found there. After changing my $PATH to point to other bins before anaconda3, everything compiled without issues.
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Configure fails to detect proper ld on a 64-bit system with 32-bit userland

I have an i386 debian system running in an lxc container. The userland is 32 bit, the kernel is 64 bit. Thus configure detects this:
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
Probably this is taken from the output of uname -m
I have a package which builds fine with gcc and the result is a proper 32 bit binary. Unfortunately in another c++ project I get this:
configure:8595: checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries
From here on the linker is using this switch and thus will try to link 64 bit libs instead of 32 bit and it fails:
/usr/bin/ld: skipping incompatible /usr/lib/libboost_program_options.so when searching for -lboost_program_options
/usr/bin/ld: skipping incompatible /usr/lib/libboost_program_options.a when searching for -lboost_program_options
/usr/bin/ld: cannot find -lboost_program_options
collect2: ld returned 1 exit status
Though the library .so file is the proper 32 bit ELF:
file /usr/lib/libboost_program_options.so.*
/usr/lib/libboost_program_options.so.1.42.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
What's odd is that configure works fine for the other project and the linker is detected correctly to use the proper arch (elf_i386):
checking whether the gcc linker (/usr/bin/ld -m elf_i386) supports shared libraries... yes
Any hints?
I just remove unknown for the syntax of command.
The problem is the target: /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/
An idea to reconfigure target in a conf flie?
This works for me:
Replace:
./configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu \
--target=x86_64-unknown-linux-gnu --options...
By:
./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --options...
Probably this is taken from the output of uname -m
This configure script is clearly confused.
To un-confuse it, tell it exactly what you want it to do:
./configure --host=i686-unknown-linux-gnu --build=i686-unknown-linux-gnu \
--target=i686-unknown-linux-gnu

'configure' failing with Android NDK standalone toolchain

I'm trying to build something with the Android NDK standalone compiler toolchain, but I'm getting this error:
Updating bundled third-party dependencies...
bash -c 'mkdir -p output/{debug,release,test}/{FCollada/{FCDocument,FMath,FUtils,FColladaTest/{FCTestAssetManagement,FCTestExportImport,FCTestXRef}},FColladaPlugins/FArchiveXML}'
cp output/libFColladaSD.a ../lib/libFColladaSD.a
cp output/libFColladaSR.a ../lib/libFColladaSR.a
Building SpiderMonkey...
SpiderMonkey build options: --disable-tests
loading cache ./config.cache
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking for mawk... mawk
checking for perl5... no
checking for perl... /usr/bin/perl
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for c++... arm-linux-androideabi-g++
checking whether the C++ compiler (arm-linux-androideabi-g++ ) works... no
configure: error: installation or configuration problem: C++ compiler cannot create executables.
ERROR: SpiderMonkey build failed
This is what the config.log says: http://pastebin.com/5AFZG4CX
My ANDROID_NDK_ROOT is set as follows:
afeder#ubuntu:~/android/0ad/build/workspaces$ echo $ANDROID_NDK_ROOT
/home/afeder/android/android-ndk-r7-crystax-4
What might be the cause or how do I debug it? Thank you.
To me this looks broken:
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
Here's how I'd set up the environment for my Android NDK build:
export CROSS_COMPILE=arm-linux-androideabi
export CC=${CROSS_COMPILE}-gcc
export CXX=${CROSS_COMPILE}-g++
... other binutils as needed ...
export NDK=/home/afeder/android/android-ndk-r7-crystax-4
export SYSROOT=$NDK/platforms/android-8/arch-arm
PATH=$PATH:$NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
Make sure and add --sysroot=$SYSROOT to CFLAGS, CPPFLAGS, and/or CXXFLAGS.
Now you need to tell the spidermonkey configure that you are cross compiling:
./configure --build=x86_64-unknown-linux-gnu --host=arm-linux-androideabi --target=arm-linux-androideabi
It looks like it can't find arm-linux-androideabi-g++. Try searching for it in the NDK folder and adding the directory to your PATH.
Mine is here:
ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-g++

solaris - compile 64bit gcc - elf class error

I'm installing a modern version of gcc on solaris. I compiled gmp, mpfr and mpc, they're all 64bit. When I try to configure gcc as follows I get an error complaining that mpc,mpfr and gmp are the wrong elf class. What gives?
./../gcc-4.5.1/configure --prefix=/opt/OurAppDir/gcc --with-gmp=/opt/OurAppDir/gmp --with-mpfr=/opt/OurAppDir/mpfr --with-gnu-as --with-gnu-ld --build=sparc-sun-solaris2.10
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
checking for a BSD-compatible install... ./../gcc-4.5.1/install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
config.log errors
configure:5474: checking for the correct version of gmp.h
configure:5494: gcc -c -g -O2 -I/opt/OurAppDir/gmp/include -I/opt/OurAppDir/mpfr/include conftest.c >&5
configure:5494: $? = 0
configure:5512: gcc -c -g -O2 -I/opt/OurAppDir/gmp/include -I/opt/OurAppDir/mpfr/include conftest.c >&5
configure:5512: $? = 0
configure:5513: result: yes
configure:5529: checking for the correct version of mpfr.h
configure:5547: gcc -c -g -O2 -I/opt/OurAppDir/gmp/include -I/opt/OurAppDir/mpfr/include conftest.c >&5
configure:5547: $? = 0
configure:5564: gcc -c -g -O2 -I/opt/OurAppDir/gmp/include -I/opt/OurAppDir/mpfr/include conftest.c >&5
configure:5564: $? = 0
configure:5565: result: yes
configure:5582: checking for the correct version of mpc.h
configure:5599: gcc -c -g -O2 -I/opt/OurAppDir/gmp/include -I/opt/OurAppDir/mpfr/include conftest.c >&5
configure:5599: $? = 0
configure:5615: gcc -c -g -O2 -I/opt/OurAppDir/gmp/include -I/opt/OurAppDir/mpfr/include conftest.c >&5
configure:5615: $? = 0
configure:5616: result: yes
configure:5634: checking for the correct version of the gmp/mpfr/mpc libraries
configure:5665: gcc -o conftest -g -O2 -I/opt/OurAppDir/gmp/include -I/opt/OurAppDir/mpfr/include -R/usr/sfw/lib/sparcv9 conftest.c -L/opt/OurAppDir/gmp/lib -L/opt/OurAppDir/m
pfr/lib -lmpc -lmpfr -lgmp >&5
ld: fatal: file /opt/OurAppDir/mpfr/lib/libmpc.so: wrong ELF class: ELFCLASS64
ld: fatal: file /opt/OurAppDir/mpfr/lib/libmpfr.so: wrong ELF class: ELFCLASS64
ld: fatal: file /opt/OurAppDir/gmp/lib/libgmp.so: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to conftest
With the default configure line, GCC will not be built as a 64-bit binary, but as 32-bit. So, you need to rebuild GMP, MPFR and MPC in 32-bit mode, by forcing configure ABI=32.
Alternatively, you can configure GCC with a sparc64-sun-solarisX build triplet. In that case, there are additional instructions on the GCC website.
You don't need 64-bit gcc binaries in order to build 64-bit application. The OpenCSW Solaris packages provide 32-bit compiler with 32-bit and 64-bit targets.
I assume you care more about being able to generate 64-bit binaries from your gcc, and less about gcc itself being 64-bit.
The way to build both 32-bit and 64-bit targets, you need to build gmp two times, once 32-bit and once 64-bit. Then you have the following layout (the example is taken from package's pkgmap):
1 f none /opt/csw/include/gmp-32.h 0644 root bin 86213 38841 1316878625
1 f none /opt/csw/include/gmp-64.h 0644 root bin 86218 39139 1316879685
1 f none /opt/csw/include/gmp.h 0755 root bin 159 12880 1316879688
1 f none /opt/csw/include/gmpxx-32.h 0644 root bin 114646 51865 1316878625
1 f none /opt/csw/include/gmpxx-64.h 0644 root bin 114646 51865 1316879685
1 f none /opt/csw/include/gmpxx.h 0755 root bin 163 13360 1316879688
1 s none /opt/csw/lib/libgmp.so=libgmp.so.10.0.2
1 s none /opt/csw/lib/libgmpxx.so=libgmpxx.so.4.2.2
1 s none /opt/csw/lib/libgmp.so.10=libgmp.so.10.0.2
1 f none /opt/csw/lib/libgmp.so.10.0.2 0755 root bin 462552 51359 1316878625
1 s none /opt/csw/lib/sparcv9/libgmp.so.10=libgmp.so.10.0.2
1 f none /opt/csw/lib/sparcv9/libgmp.so.10.0.2 0755 root bin 503424 11223 1316879684
The GCC build system is smart enough to know to look into /opt/csw/lib/sparcv9 for the 64-bit libraries and into /opt/csw/lib for the 32-bit libraries.
The gmp.h header file is a wrapper, which contains an #ifdef statement, including gmp-32.h or gmp-64.h depending on the compilation mode requested.
/* Allow 32 and 64 bit headers to coexist */
#if defined __amd64 || defined __x86_64 || defined __sparcv9
#include "gmp-64.h"
#else
#include "gmp-32.h"
#endif
The gmp library is the only one which requires this kind of header file wrapper; the mpc, mpfr, ppl and cloog libraries don't vary the header files depending on the architecture / word length.
When you compile gcc with 64-bit targets, you get a layout with two crt1.o files:
/opt/csw/lib/gcc/sparc-sun-solaris2.9/4.6.2/crt1.o
/opt/csw/lib/gcc/sparc-sun-solaris2.9/4.6.2/sparcv9/crt1.o
This way, when you pass -m64, gcc will produce a 64-bit binary.

Resources