gcc error: command '/usr/bin/gcc' failed with exit status 1 - c++

Several months ago I ran a build file and working without any problem. after that, when I update Ubuntu 14 and run that again, got some unexpected errors:
running build_ext
building 'allthethings' extension
/usr/bin/gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch
i386 -arch x86_64 -fPIC
-I/home/xin/anaconda2/lib/python2.7/site-packages/numpy/core/include
-I/home/xin -I/usr/include
-I/home/xin/anaconda2/include/python2.7 -c allthethings.cpp -o
build/temp.linux-x86_64-2.7/allthethings.o -fopenmp
gcc: error: i386: No such file or directory
gcc: error: x86_64: No such file or directory
gcc: error: unrecognized command line option ‘-arch’
gcc: error: unrecognized command line option ‘-arch’
error: command '/usr/bin/gcc' failed with exit status 1
I am not sure what is wrong, since the input source flag of file, is real simple:
export ARCHFLAGS=""
export CFLAGS="-arch i386 -arch x86_64"
The main part of the build_ext is shown bellow:
os.environ["CC"] = "/usr/bin/gcc"
os.environ["CXX"] = "/usr/bin/g++"
from distutils.core import setup, Extension
from Cython.Build import cythonize
from Cython.Distutils import build_ext
import numpy
print 'start'
setup(ext_modules=cythonize(Extension(
"allthethings", # the extesion name
sources=["allthethings.pyx", "channel.cpp", "setupandrun.cpp",
"file_output.cc", "network.cpp", "levmar.cpp", "mp_mat.cpp",
"str_double.cpp", "mp_mat_double.cpp", "libcla.c","setup.py"],
libraries=["lapack", "cblas", "fftw3", "m"],
language="c++",
extra_link_args=['-fopenmp'],
extra_compile_args=['-fopenmp'],
include_dirs=[numpy.get_include(),"/home/xin", "/usr/include"]
)))
Thanks for anyone help. I'm not sure, but maybe the error is due to recent updates of ubuntu14. It is very difficult for me to solve that, since I do not know what the error message means.
gcc -v shows:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.3- 8ubuntu2~14.04'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.3 (Ubuntu 4.9.3-8ubuntu2~14.04)

Related

Using gcc compile some package statically got an error about libprocps.a

# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
Well, I'm trying to compile my code staitcally with gcc:
g++ build/test.o -o build/test -std=c++11 -DCURVE_MNT4 -DNO_PROCPS -I ./src/ -static -lm -lff -lstdc++ -lgmpxx -lgmp -lprocps
that code works perfectly fine if you just run the same command without "-static" flag, but because of the project need, we have to compile this code statically, so we have to use "-static" flag and here are some logs:
# g++ build/test.o -o build/test -std=c++11 -DCURVE_MNT4 -DNO_PROCPS -I ./src/ -static -lm -lsnark -lff -lstdc++ -lgmpxx -lgmp -lprocps
......
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libprocps.a(pwcache.o): In function `pwcache_get_group':
(.text+0x1c8): warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libprocps.a(pwcache.o): In function `pwcache_get_user':
(.text+0x58): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libprocps.a(readproc.o): In function `sd2proc':
(.text+0x1233): undefined reference to `sd_pid_get_machine_name'
(.text+0x1247): undefined reference to `sd_pid_get_owner_uid'
(.text+0x1296): undefined reference to `sd_pid_get_session'
(.text+0x12b1): undefined reference to `sd_session_get_seat'
(.text+0x12c7): undefined reference to `sd_pid_get_slice'
(.text+0x12dd): undefined reference to `sd_pid_get_unit'
(.text+0x12f3): undefined reference to `sd_pid_get_user_unit'
collect2: error: ld returned 1 exit status
Makefile:22: recipe for target 'build/test' failed
make: *** [build/test] Error 1
any idea guys?
I hope there is a way to solve this problem, the "gcc " way or "ar -r" way or an alternative to “libprocps.a” is fine to me, I just want to know how can I compile successfully with flag "-static", thank you all
Recompiling libprocps without systemd support (--with-systemd=no) got rid of the systemd dependency and allowed #Will_Z to create a fully statically linked binary.

Cannot Build Boost 1.47.0 IOStreams on Ubuntu

I am working on a legacy project for my company that requires me to use a specific version of boost and that version is 1.47.0. I have downloaded and run:
./b2 --toolset=gcc variant=debug
and it compiled the majority of the static libraries I needed with the exception of a few. One being libboost_iostreams. I did some research and found that it appeared i was missing some dependencies.
whereis bzip2
bzip2: /bin/bzip2 /usr/share/man/man1/bzip2.1.gz
whereis zlib
zlib: /usr/include/zlib.h /usr/share/man/man3/zlib.3.gz
However when I attempt to run:
./b2 --with-iostreams -s BZIP2_SOURCE=/bin -s ZLIB_SOURCE=/usr/include
I am getting the following error:
Building the Boost C++ Libraries.
error: Unable to find file or target named
error: '/bin/libbz2.def'
error: referred from project at
error: 'libs/iostreams/build'
Update:
Linux Version: 16.04
Gcc Version Info:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-
6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --
enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --
program-suffix=-5 --enable-shared --enable-linker-build-id --
libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --
libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-
libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-
plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --
enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --
enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --
with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-
directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-
objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-
abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-
tune=generic --enable-checking=release --build=x86_64-linux-gnu --
host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)

Prefer sysroot headers over headers in the toolchain using gcc

I'm trying to cross-compile a simple code snippet
1 #include <sys/socket.h>
2 #include <stdio.h>
3
4 int main()
5 {
6 printf("%d\n", SOL_NETLINK);
7 return 0;
8 }
with arm-linux-gnueabihf-g++ (from Ubuntu) against Raspbian sysroot with --sysroot switch set to $SYSROOT
The compilation fails with this error:
test.cpp:6:20: error: ‘SOL_NETLINK’ was not declared in this scope
Even though $SYSROOT/usr/include/arm-linux-gnueabihf/bits/socket.h contains
the needed define.
So I figured that toolchain contains the mentioned header as well and it's included first. The latter header somehow doesn't have this SOL_NETLINK define. So I need a way to tell the compiler to prefer the toolchain's headers to sysroot's ones.
> arm-linux-gnueabihf-g++ -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)
#include <sys/socket.h> will include a file which is under the folder {include path}/sys/socket.h.
Include path can be any folder that you add with various options like gcc -I or --includedir. In addition there are some default include path, which you should be able to see with gcc -xc++ -E -v -.
Using gcc "-I" option will put the include path to search first, before any of the default include paths.
Now, this should give you enough information to understand that the include you give can't point to the file $SYSROOT/usr/include/arm-linux-gnueabihf/bits/socket.h as it isn't end with {include path}/sys/socket.h
Use -isystem flag with $SYSROOT/usr/include/arm-linux-gnueabihf
Albeit GCC can resolve triple (arm-linux-gnueabihf part) in the path, but it won't do so with --sysroot option.

Ubuntu 17.04 C++ project compilation output wrong type

I upgraded yesterday Ubuntu 16.04 to 17.04 and made a new compliation of my C++ projects. But it ouputs me a shared object file and it supposed to output an executable file of course.
I can execute it from command line but I can't launch the soft from the UI. It worked well in version 16.04.
Here is the end of the compilation:
echo Linking wxFlasher...
mkdir -p /home/barnaud/dev/wxFlasher/wxFlasher/out_gcc/releaseu/
rm -f /home/barnaud/dev/wxFlasher/wxFlasher/out_gcc/releaseu/wxFlasher
g++ -s -o /home/barnaud/dev/wxFlasher/wxFlasher/out_gcc/releaseu/wxFlasher /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Main/Application.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Main/ResourceManager.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Main/Event.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Main/Thread.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Main/Utils.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/HMI/MainFrame.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/HMI/PnlFlasher.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/HMI/DlgAbout.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/HMI/PnlUpdater.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/HMI/PnlDump.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/HMI/PnlRegen.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/PlfManagement.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/UpdaterThread.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/UpdaterFactory.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/UartUpdaterProtocol.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/UartBootloaderProtocol.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/UsbUpdaterProtocol.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/UsbBootloaderProtocol.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/UsbOmap3630Protocol.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/TestProtocolThread.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/RegenProtocolThread.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Protocol/posix_crc.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Communication/libusb.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Communication/Uart.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Config/ProductCfg.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Config/ProductXml.o /home/barnaud/dev/wxFlasher/wxFlasher/build_gcc/releaseu/Config/UpdaterCfg.o -L/usr/lib/x86_64-linux-gnu -pthread -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0
Any ideas ?
EDIT :
Here is the output of file command:
wxFlasher: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3c57f7ee667e4ba8be74a0392d9574a91918fa0e, not stripped
And here is the output of g++ -v command:
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.3.0-12ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)

Linker Error cutest binary with matlab

I need to implement a library with mathematical problems to test an algorithm I wrote in matlab. The library is called "cutest" (see here: http://ccpforge.cse.rl.ac.uk/gf/project/cutest/wiki/).
As I am using Ubuntu, it's not possible to install this thing via the homebrew repo. Therefore I was doing the manual installation and was able to install cutest and the problemdecoder "sifdec" (also downloadable ob the page above).
I am now stuck in the point, where I need to compile a binaryfile that can be used by matlab. I guess it has something to do with the compiler flags of fortran/gcc and a 32/64 bit thing (as I was already scrolling through other posts and google).
The Error I get is the following:
/usr/bin/ld: i386 architecture of input file `/home/beck/CUTEst/cutest
/objects/pc64.lnx.gfo/double/mcutest.o' is incompatible with i386:x86-64
output
/usr/bin/ld: /home/beck/CUTEst/cutest/objects/pc64.lnx.gfo/double
/mcutest.o: file class ELFCLASS32 incompatible with ELFCLASS64
/usr/bin/ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status
mex: link of ' "mcutest.mexa64"' failed.
The mex file is from matlab, I didn't modify it yet (nor the optionsfile for mex).
The settings for the makefile "pc64.lnx.gfo", which I created (automatically) via a terminal installation are the following:
# Architecture dependent makefile
# (automatically generated by install_cutest)
VERSION = pc64.lnx.gfo
# Basic system commands
CP = /bin/cp
MV = /bin/mv
RM = /bin/rm -f
SED = /bin/sed
GREP = /bin/grep
AR = /usr/bin/ar
RANLIB = /usr/bin/ranlib
# Directory for binaries
PRECIS = double
OBJ = $(CUTEST)/objects/$(VERSION)/$(PRECIS)
OBJS = $(CUTEST)/objects/$(VERSION)/single
OBJD = $(CUTEST)/objects/$(VERSION)/double
MOD = $(CUTEST)/modules/$(VERSION)/$(PRECIS)
SEDS = $(CUTEST)/seds/$(PRECIS).sed
MVMODS = $(MV) -f $(OBJ)/*.mod $(MOD)/ || true
# Compiler options
FORTRAN = gfortran-4.7
BASIC = -c -fno-second-underscore -fPIC
MODULES = -I$(MOD)
OPTIMIZATION = -O
NOOPTIMIZATION = -O0
DEBUG =
OPENMP = -fopenmp
F77 = -ffixed-form
F90 =
F95 =
NOFMAIN =
USUAL =
SPECIAL =
F77SUFFIX = f90
F95SUFFIX = f90
TIMER = GEN
NOT95 = IS95
NOT64 = IS64
AMPLDIR =
CC = gcc-4.7
CCBASIC = -c -ansi -pedantic -fPIC
CCONDEF =
CCDEBUG =
CCFFLAGS = -lgfortran
# Special flags
# Libraries
BLAS =
LAPACK =
CUTESTUSED =
# Shell used
BINSHELL = sh
# Set directories for optional packages
include $(CUTEST)/src/makedefs/packages
# Body of makefile
include $(PWD)/makemaster
I'd really appreciate any kind of help, this issue keeps me from going further with my master thesis.
EDIT: Added outputs of gcc-4.7/gfortran-4.7 -v
gcc-4.7 -v:
Using built-in specs.
COLLECT_GCC=gcc-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.4-3ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-3ubuntu3)
gfortran-4.7 -v:
Using built-in specs.
COLLECT_GCC=gfortran-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.4-3ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-3ubuntu3)
I was able to solve the problem with the help of an academic member of my university. In case anyone has/will have the same problem here is what worked for me:
As the toolchain was 64-bit and the only file that was generated in 32-bit was the mcutest.o the error had to be in combination with the mex compilation (cause only this file was compiled with the mex compiler of matlab).
Inside the folderstructure was a file called makemaster which holds the settings alredy choosen in the installation progress for gfortran and gcc, but also settings for mex (which i wasn't asked to modify yet). However, after some testing, adding the line CFLAGS='$(CFLAGS)' in the MFLAGS resulted in a 64-bit output file and the error didn't occur anymore.
Thanks for your help anyway!