configure: error: C compiler cannot create executables - Mac Sierra - c

I know these have been posted before, but I'm stuck and can't seem to get anywhere, even by reading copious responses to similar issues to mine.
I get the dreaded "C compiler cannot..." from the title of this post.
I'm on macOS Sierra (long story as to why I'm behind), and have XCode CLT 9.2 installed. I ditched the full XCode app and just went down to the CLT - installed from the Dev area.
Otherwise, I have the latest Homebrew, GCC, Dialog, Libtool, and Automake/Autoconf - some were pre-reqs for the LIRC system I'm trying to get compiled and installed (IR subsystem).
brew config shows that it properly sees the correct XCode CLT, so my guess is that that part is ok.
I get errors once I run the ./configure for this system I'm trying to get up and running...here's the output:
Configuration: .setup.config, executable shell script: configure.sh
Starting the generated shell script which will call configure with the right
parameters...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./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 whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Volumes/Macintosh HD Giant/Users/Nidocamen/Downloads/LIRC-port-for-Mac-OS-X-master':
configure: error: C compiler cannot create executables
See `config.log' for more details
Thought it could be a permissions issue on the LIRC folder, but it's accessible.
I put in a symlink to ensure that gcc is running gcc-9 in /usr/local/bin and ensured that that path is before /usr/bin (brew doctor isn't complaining about that anymore).
Anyways, I'm otherwise really not sure what's causing this to fail. I've been a developer before, but more on the web app side of things and not at this level.
If anyone has some suggestions, I'd love to hear them...thanks! :)
UPDATE - here's some output from the log that would appear to narrow this down. While the people who created this install claims it works well on recent macOS version, it seems like some of the code used is really outdated and that could be why it's not compiling.
Configured with: ../configure --build=x86_64-apple-darwin16 --prefix=/usr/local/Cellar/gcc/9.2.0 --libdir=/usr/local/Cellar/gcc/9.2.0/lib/gcc/9 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-9 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 9.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
Thread model: posix
gcc version 9.2.0 (Homebrew GCC 9.2.0)
configure:3322: $? = 0
configure:3311: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3322: $? = 1
configure:3311: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:3322: $? = 1
configure:3342: checking whether the C compiler works
configure:3364: gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.9 conftest.c >&5
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
configure:3368: $? = 1
configure:3406: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define PACKAGE "lirc"
| #define VERSION "0.9.1-git"
| /* end confdefs.h. */

I had a similar issue, and in my case the "library not found for -lSystem" was caused by a line in my .bash_profile
alias openclc=/System/Library/Frameworks/OpenCL.framework/Libraries/openclc
No idea why I had put that in there, but unalias-ing it fixed my issues...

Related

cross compiling with autoconf

I was trying to cross compile with autoconf.
I had tried from these helps :
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html
https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html
https://github.com/jedisct1/libsodium/issues/274
Cross Compiling For ARM With Autoconf
And did -
./configure --build=x86_64-linux-gnu --host=/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf --target=/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf --disable-shared --disable-documentation
But after autoconf tool checking for the gcc and other things necessary for compilation it doesn't find these. Although they are already present in the directory.
So the log is :
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc... no
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... yes
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 whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ar... no
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-lib... no
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-link... no
checking for ar... ar
checking the archiver (ar) interface... ar
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf': machine `/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm' not recognized
configure: error: /bin/bash ./config.sub /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf failed
This is the directory for all arm toolchain bin
host#ubuntu:/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin$ ls
arm-linux-gnueabihf-addr2line arm-linux-gnueabihf-gcc arm-linux-gnueabihf-gfortran arm-linux-gnueabihf-readelf
arm-linux-gnueabihf-ar arm-linux-gnueabihf-gcc-5.4.1 arm-linux-gnueabihf-gprof arm-linux-gnueabihf-size
arm-linux-gnueabihf-as arm-linux-gnueabihf-gcc-ar arm-linux-gnueabihf-ld arm-linux-gnueabihf-strings
arm-linux-gnueabihf-c++ arm-linux-gnueabihf-gcc-nm arm-linux-gnueabihf-ld.bfd arm-linux-gnueabihf-strip
arm-linux-gnueabihf-c++filt arm-linux-gnueabihf-gcc-ranlib arm-linux-gnueabihf-nm gdbserver
arm-linux-gnueabihf-cpp arm-linux-gnueabihf-gcov arm-linux-gnueabihf-objcopy runtest
arm-linux-gnueabihf-elfedit arm-linux-gnueabihf-gcov-tool arm-linux-gnueabihf-objdump
arm-linux-gnueabihf-g++ arm-linux-gnueabihf-gdb arm-linux-gnueabihf-ranlib
Any suggestion?
EDIT
I tried the solution suggested by Chrono. It was able to find arm toolchain. But another problem arised :
error adding symbols: File format not recognized
libtool: link: arm-linux-gnueabihf-gcc -shared -fPIC -DPIC src/.libs/libcoap_1_la-address.o src/.libs/libcoap_1_la-async.o src/.libs/libcoap_1_la-block.o src/.libs/libcoap_1_la-coap_dtls.o src/.libs/libcoap_1_la-coap_event.o src/.libs/libcoap_1_la-coap_keystore.o src/.libs/libcoap_1_la-coap_time.o src/.libs/libcoap_1_la-debug.o src/.libs/libcoap_1_la-encode.o src/.libs/libcoap_1_la-hashkey.o src/.libs/libcoap_1_la-mem.o src/.libs/libcoap_1_la-net.o src/.libs/libcoap_1_la-option.o src/.libs/libcoap_1_la-pdu.o src/.libs/libcoap_1_la-resource.o src/.libs/libcoap_1_la-str.o src/.libs/libcoap_1_la-subscribe.o src/.libs/libcoap_1_la-uri.o src/platform/posix/.libs/libcoap_1_la-coap_io.o src/platform/posix/.libs/libcoap_1_la-prng.o src/platform/posix/.libs/libcoap_1_la-run.o -L./ext/tinydtls -ltinydtls -g -O2 -Wl,--version-script=./libcoap-1.map -Wl,-soname -Wl,libcoap-1.so.0 -o .libs/libcoap-1.so.0.0.0
For this line of compilation the error is :
./ext/tinydtls/libtinydtls.a: error adding symbols: File format not recognized
EDIT 2:
The problem was with the library it is not passing the cross compiler params to the autoconf properly, hence the issue.
Ensure the directory containing your toolchain's binaries is in your $PATH:
export OLDPATH=$PATH
export PATH=$OLDPATH:/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin
You should only need to do that once, unless you log out or otherwise exit that terminal session.
With that done, you can configure properly:
./configure \
--build=x86_64-linux-gnu \
--host=arm-linux-gnueabihf \
--target=arm-linux-gnueabihf \
--disable-shared \
--disable-documentation

configure tries to test-run a cross compiled program

I try to compile something for IBM Blue Gene/Q with GCC 4.9. As a dependency I need the gmp (GNU Multi Precision) library, I use version 6.1.1. This comes with GNU Autotools.
Strangely, is has worked with LLVM before. And yesterday it did not work at noon but again in the evening and not any more today. I am thoroughly confused, honestly.
On Blue Gene/Q, you compile on an IBM PowerPC 740 and let it run on an IBM PowerPC A2 processor. Therefore you need to use the cross compiler. My configure is the following:
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure \
--prefix=/homec/hbn28/hbn28e/local-juqueen \
--host=powerpc64-bgq-linux \
--build=powerpc64-unknown-linux-gnu \
--disable-shared \
--enable-static \
CC=/bgsys/local/gcc/4.9.3/bin/mpigcc \
CXX=/bgsys/local/gcc/4.9.3/bin/mpig++ \
'CFLAGS=-O2 \
-finline-limit=50000 \
-Wall \
-Wpedantic \
-fmax-errors=1 \
-fdiagnostics-color=auto \
-Drestrict=__restrict__ \
--std=gnu99'
Error regarding CC_FOR_BUILD
The first issue has been this error.
/usr/include/stdio.h:34:21: error: stddef.h: No such file or directory
The generated Makefile has used CC for a few files but then called itself recurively using CC=$(CC_FOR_BUILD). And that is just set to cc by default, the frontend compiler which does not do any good on the compute backend. So I have added CC_FOR_BUILD=/bgsys/local/gcc/4.9.3/bin/mpigcc to the configure flags. That fixed that error.
Testing cross compiled binary
Then the configure script runs a bit further:
checking build system type... powerpc64-unknown-linux-gnu
checking host system type... powerpc64-bgq-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for powerpc64-bgq-linux-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=mode64
checking whether /bgsys/local/gcc/4.9.3/bin/mpigcc is gcc... yes
checking compiler /bgsys/local/gcc/4.9.3/bin/mpigcc -O2 -finline-limit=50000 -Wall -Wpedantic -fmax-errors=1 -fdiagnostics-color=auto -Drestrict=__restrict__ --std=gnu99 ... yes
checking compiler /bgsys/local/gcc/4.9.3/bin/mpigcc -O2 -finline-limit=50000 -Wall -Wpedantic -fmax-errors=1 -fdiagnostics-color=auto -Drestrict=__restrict__ --std=gnu99 has sizeof(long)==8... yes
checking for powerpc64-bgq-linux-gcc... /bgsys/local/gcc/4.9.3/bin/mpigcc
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... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /bgsys/local/gcc/4.9.3/bin/mpigcc accepts -g... yes
checking for /bgsys/local/gcc/4.9.3/bin/mpigcc option to accept ISO C89... none needed
checking whether /bgsys/local/gcc/4.9.3/bin/mpigcc understands -c and -o together... yes
checking for /bgsys/local/gcc/4.9.3/bin/mpigcc option to accept ISO C99... none needed
checking for /bgsys/local/gcc/4.9.3/bin/mpigcc option to accept ISO Standard C... (cached) none needed
checking how to run the C preprocessor... /bgsys/local/gcc/4.9.3/bin/mpigcc -E
checking build system compiler /bgsys/local/gcc/4.9.3/bin/mpigcc... no
configure: error: Specified CC_FOR_BUILD doesn't seem to work
Looking at config.log, it says
configure:9899: checking build system compiler /bgsys/local/gcc/4.9.3/bin/mpigcc
configure:9912: /bgsys/local/gcc/4.9.3/bin/mpigcc conftest.c
configure:9915: $? = 0
/bgsys/source/srcV1R2M4.29840/comm/sys/buildtools/pami/common/bgq/BgqPersonality.h:102:
/bgsys/source/srcV1R2M4.29840/comm/sys/buildtools/pami/common/bgq/BgqPersonality.h<102>
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 10000: 26929 Aborted (core dumped) ./a.out
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./b.out: No such file or directory
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./a.exe: No such file or directory
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./a_out.exe: No such file or directory
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./conftest: No such file or directory
configure:9922: result: no
configure:9927: error: Specified CC_FOR_BUILD doesn't seem to work
It seems to use the correct compiler. When running the program on the frontend (where I compile), it fails since the BgqPersonality.h has special information about the compute backend, the program just cannot run on the frontend.
configure assumes that the compiler is broken (which it arguably is for the frontend) and stops building. Previously I had neither error with LLVM, the cross compilation has just worked fine. configure even says checking whether we are cross compiling... yes so it must be aware of the situation. Perhaps the CC_FOR_BUILD is meant for the frontend whereas CC is for the compute backend. Without CC_FOR_BUILD I cannot compile as written above.
Is there some way to get this cross compiled properly?
CC_FOR_BUILD is supposed to be a compiler that can compile tools for the current system, rather than the one you want to build the binaries for. The name comes from the fact that CBUILD is the name to reference the system the build happens on.
I wrote a blog post some time ago that explains the nomenclature of these systems and how they are supposed to be used.

fltk complains about gcc on windows

I've been trying for almost a to build fltk on windows in so many different ways but I always end up with:
configure: error: C compiler cannot create executable
(msys fltk/configure)
or
Check for working C compiler: C:/MinGW/bin/gcc.exe -- broken
(CMake-gui)
I've tried it with fltk 1.3.0 and 1.3.3 and I've even used three different MinGW distros, GCC version: 5.1.0; 4.9.2 and 3.4.5. Yet it just won't compile. Here is some of the error log generated by the ./configure file:
$ ./configure --prefix=C:/libs/fltk-1.3.3
-----------
Core tests.
-----------
configure:1336: checking build system type configure:1354: result:
i686-pc-mingw32 configure:1362: checking host system type
configure:1376: result: i686-pc-mingw32 configure:1439: checking for
gcc configure:1455: found /c/mingw32/bin/gcc configure:1465: result:
gcc configure:1709: checking for C compiler version configure:1712:
gcc --version &5 gcc.exe (i686-win32-dwarf-rev2, Built by
MinGW-W64 project) 4.9.2 Copyright (C) 2014 Free Software Foundation,
Inc. This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
configure:1715: $? = 0 configure:1717: gcc -v &5 Using
built-in specs. COLLECT_GCC=c:\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw32/bin/../libexec/gcc/i686-w64-mingw32/4.9.2/lto-wrapper.exe
Target: i686-w64-mingw32 Configured with:
../../../src/gcc-4.9.2/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw492/i686-492-win32-dwarf-rt_v4-rev2/mingw32 --with-gxx-include-dir=/mingw32/i686-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=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --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=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw492/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw492/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw492/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw492/prerequisites/i686-w64-mingw32-static --with-cloog=/c/mingw492/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-win32-dwarf-rev2, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw492/i686-492-win32-dwarf-rt_v4-rev2/mingw32/opt/include -I/c/mingw492/prerequisites/i686-zlib-static/include -I/c/mingw492/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-I/c/mingw492/i686-492-win32-dwarf-rt_v4-rev2/mingw32/opt/include -I/c/mingw492/prerequisites/i686-zlib-static/include -I/c/mingw492/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe
-L/c/mingw492/i686-492-win32-dwarf-rt_v4-rev2/mingw32/opt/lib -L/c/mingw492/prerequisites/i686-zlib-static/lib -L/c/mingw492/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware' Thread model: win32 gcc version 4.9.2 (i686-win32-dwarf-rev2, Built by MinGW-W64 project) configure:1720:
$? = 0 configure:1722: gcc -V &5 gcc.exe: error:
unrecognized command line option '-V' gcc.exe: fatal error: no input
files compilation terminated. configure:1725: $? = 1 configure:1748:
checking for C compiler default output configure:1751: gcc
conftest.c >&5
c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x39):
undefined reference to `WinMain#16' collect2.exe: error: ld returned 1
exit status configure:1754: $? = 1 configure: failed program was: |
line 1728 "configure" | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define
PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h.
*/ | | int main () | { | | ; | return 0; | } configure:1793: error: C compiler cannot create executables See `config.log' for more
details.
configure: exit 77
I previously compiled 2 other gui libraries with these same tools (nana and SFML), so there can't be anything wrong with the gcc compilers.
EDIT
Something (most probably cygwin) keeps breaking my mingw gcc program and every time its "broken" I get black vcc1.exe windows. Then I must replace the mingw folder to get it working again, this happens mostly when I open netbeans. I just don't know how to fix this, so I've just been avoiding cygwin and netbeans.
I was finally able to build it yesterday with this version of TDM-GCC (as per the gui installer):
MinGW-w64/TDM64 (32-bit and 64-bit) ==> TDM-GCC
I used he cmake gui instead of the .configure 1. open cmake gui. 2. input the source code folder (root of fltk folder, ie: "C:/libs/fltk-1.3.3"). 3. input the build folder, ie: "C:/libs/fltk-1.3.3/build/". 4. click configure 5. ** optionally you can change some options but i didn't 6. click Genertae 7. in cmd (I used git bash though): cd to the build directory and run make or mingw32-make
I completely uninstalled cygwin because of its interference with the tool chain builds, i.e mingw and tdm-gcc (Still not sure why this happens).
An easier way to setup a development environment is to use MSYS2.
Download and install
Run MSYS2 Shell
Install some dev tools anf FLTK: pacman -S make automake autoconf libtool mingw-w64-i686-gcc mingw-w64-i686-fltk
Run Mingw64 Shell and you'll be able to easily compile your source: g++ -o myproject myproject.cpp -lfltk

gcc creates a different folder base on its version

When I try to rpmbuild something I got this error message
checking for x86_64-redhat-linux-gcc... no
checking for gcc... no
checking for x86_64-redhat-linux-cc... no
checking for cc... no
checking for x86_64-redhat-linux-cl.exe... no
checking for cl.exe... no
And I found out that, the tool are in /usr/bin/gcc48 what I did is link the gcc48 to gcc folder: Which I got the idea from this link https://stackoverflow.com/a/13327320/612920
ln /usr/bin/gcc48 /usr/bin/gcc
And when I tried to run rpmbuild again I got this error message:
checking for x86_64-redhat-linux-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/usr/src/rpm/BUILD/courier-unicode-1.1':
configure: error: C compiler cannot create executables
See `config.log' for more details
error: Bad exit status from /var/tmp/rpm-tmp.jrbnrw (%prep)
What is wrong? I had already installed all development tools and its on its latest versions. Can Somebody help me?
And by the way I am using Amazons Redhat (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC))
UPDATED:
config.log
configure:3499: $? = 0
configure:3488: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-amazon-linux/4.8.2/lto-wrapper
Target: x86_64-amazon-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugu$
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
configure:3499: $? = 0
configure:3488: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3488: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3519: checking whether the C compiler works
configure:3541: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp$
collect2: fatal error: cannot find 'ld'
compilation terminated.
configure:3545: $? = 1
configure:3583: result: no
configure: failed program was:
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3588: error: in `/home/falko/rpm/BUILD/courier-unicode-1.1':
configure:3590: error: C compiler cannot create executables
gcc is one of a number of tools required to build a software package, and as you can see from the error in your config.log, some more are missing from your system:
collect2: fatal error: cannot find 'ld'
It is complaining that it cannot find the system linker (ld).
Before addressing this, I recommend you set the gcc version to be used correctly. Unfortunately the advice you followed from https://stackoverflow.com/a/13327320/612920 is somewhat incomplete.
Redhat based systems provide a mechanism for being able to switch between different implementations of a piece of software at will (for example, different versions). This tool is called alternatives. You should use that to set the GCC version that will be used when you run 'gcc' at the command line. It will update a whole set of symlinks, not just the one you manually set.
sudo alternatives --config gcc
After doing this set the linker to be used:
sudo alternatives --config ld
Note that when I've tried out an AMI linux image, I found that by installing gcc like this:
sudo yum install gcc48
it automatically set the correct 'alternatives' for the newly installed compiler and corresponding linker. I'm not sure how your system got into the state that it is currently in, but if you still have problems after the above procedure, I recommend uninstalling and re-installing gcc and binutils.
After a couple of research I had found out that I am just lacking of ld(GNU linker) tool from RedHat's developer tool set and I also found out that there is an alternative tool just in case ld(GNU linker) is not available, ld.bfd(alternative to the GNU linker) which is in my case it is available. What I did, I make a link from ld.bfd to ld:
ln /usr/bin/ld.bfd /usr/bin/ld
I don't know if it is the proper solution but it works for me.
Reference: Red_Hat_Developer_Toolset

Compiling vsftpd 3.0.0 is failing

I recently tried to compile vsftpd 3.0.0 but it fails due the following compile error:
gcc -c seccompsandbox.c -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wall -W - Wshadow -Werror -Wformat-security -D_FORTIFY_SOURCE=2 -idirafter dummyinc
seccompsandbox.c:63: error: ‘O_DIRECTORY’ undeclared here (not in a function)
seccompsandbox.c:63: error: ‘O_CLOEXEC’ undeclared here (not in a function)
make: *** [seccompsandbox.o] Error 1
As I'm not very familar with the source and the environment I have no idea how to fix this. I imagine that it has something to do with the new seccomp filter sandbox. A Search on google showed me that the error is reproducible but no solution was submitted.
My linux kernel version is 2.6.32-5-amd64 and I'm using gcc version 4.4.5 (Debian 4.4.5-8)
Any ideas welcome.
(If you need additional information's don't hesitate to ask)
At least on Debian O_DIRECTORY and O_CLOEXEC are defined only if _GNU_SOURCE is defined.
Although _GNU_SOURCE is set for certain modules in the current vsftp release it is not set generally.
As a work around you might use the following patch:
diff -Naur vsftpd-3.0.0.orig/seccompsandbox.c vsftpd-3.0.0/seccompsandbox.c
--- vsftpd-3.0.0.orig/seccompsandbox.c 2012-04-05 00:41:51.000000000 +0200
+++ vsftpd-3.0.0/seccompsandbox.c 2012-06-30 15:25:52.000000000 +0200
## -11,7 +11,7 ##
#include "seccompsandbox.h"
#if defined(__linux__) && defined(__x86_64__)
-
+#define _GNU_SOURCE
#include "session.h"
#include "sysutil.h"
#include "tunables.h
Disclaimer: Applying this patch makes the current vsftp release compile, I have now clue wether the created binaries work correctly or not.
I'm using SLES 11 sp1 64bit, kernel 2.6.32, gcc ver 4.3.4; changing or removing FORTIFY_SOURCE made no difference, get same error. I'm not a c programmer - the flags O_DIRECTORY and O_CLOEXEC are in seccompsandbox.c:
static const int kOpenFlags =
O_CREAT|O_EXCL|O_APPEND|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|O_LARGEFILE;
It compiles if you remove them but that really fills me with confidence....
The vrf_findlibs.sh is also broken, I had to rejig the script so it found a 64bit version of libcap first or it keeps selecting the 32bit copy (the -lcap doesn't work either, says it isn't found):
# Look for libcap (capabilities)
if locate_library /lib64/libcap.so; then
echo "/lib64/libcap.so.2";
elif locate_library /lib/libcap.so.1; then
echo "/lib/libcap.so.1";
elif locate_library /lib/libcap.so.2; then
echo "/lib/libcap.so.2";
else
locate_library /usr/lib/libcap.so && echo "-lcap";
locate_library /lib/libcap.so && echo "-lcap";
locate_library /lib64/libcap.so && echo "-lcap";
fi

Resources