I'm "cross-compiling" Zlib with MinGW under Cygwin environment
If I run the compiler under Cygwin shell, I get a lot of strange errors:
$ /bin/i686-w64-mingw32-gcc.exe -O3 -Wall -c -o adler32.o adler32.c
/tmp/cc5e9THF.s: Assembler messages:
/tmp/cc5e9THF.s:7: Error: invalid instruction suffix for `push'
/tmp/cc5e9THF.s:8: Error: invalid instruction suffix for `push'
/tmp/cc5e9THF.s:9: Error: invalid instruction suffix for `push'
...
However, when I run the same from the Windows shell, it seems to work
"c:\cygwin64\bin\i686-w64-mingw32-gcc.exe" -O3 -Wall -c -o adler32.o adler32.c
What might be the problem?
Related
I facing some trouble compiling my programming assignment on my local machine. The program is distribute to us with makefiles and compilation commands that are known to work on the school's Scientific Linux servers. My local machine is Mac OS X El Capitan.
When I compile my program running make on my Mac, I get the following error that prevents compilation from proceeding:
myid-MacBook-Pro:mp6 myid$ make
gcc -g -lm -std=c99 -Wall -Werror -c lodepng.c
clang: error: -lm: 'linker' input unused
make: *** [lodepng.o] Error 1
But when I push that very same code as work in progress to the Linux servers and compile there, everything works fine. The linux servers use gcc and not clang:
[netid#linux-a2 mp6]$ make
gcc -g -lm -std=c99 -Wall -Werror -c functions.c
gcc -g -lm -std=c99 -Wall -Werror main.o lodepng.o imageData.o functions.o -o mp6 -lm
gcc -g -lm -std=c99 -Wall -Werror -c test.c
gcc -g -lm -std=c99 -Wall -Werror test.o lodepng.o imageData.o functions.o solution.o -o test -lm
In the makefile, these are the variable definitions:
CC=gcc
CFLAGS=-g -lm -std=c99 -Wall -Werror
and the target definition for loadpng.o
lodepng.o: lodepng.c
$(CC) $(CFLAGS) -c lodepng.c
I would appreciate any help on understanding this error and overcoming it.
Thank you very much.
Also, on this note, I thought I would say that I've noticed a subtle difference between Clang and GCC. It seems to me that even warnings generated by Clang would prevent the compilation to proceed so the warnings behaves like errors. But for GCC, if it generates warnings, it still compiles the object file. Please correct me if I'm mistaken.
Right now you're getting a compilation error on your Mac because you're trying to pass linker commands (i.e. -lm) into a compilation(i.e. -c). Do not give link flags when you compile (-c flag) your source files.
In the other compilation snippet you provided, the unused linker command seems to pass by unnoticed which isn't a good thing.
For your last question, the flag -Werror should force all compilation warnings to become errors -- which is exactly what you are describing.
I'm trying to use the Yocto Project Eclipse ADT plugin using the manual as a reference with a standalone pre-built toolchain created by running bitbake <recipename> -c populate_sdk, then running poky-glibc-x86_64-<recipename>-x86-toolchain-2.0.sh, specifying default locations. I've sourced the environment-setup in opt/poky/2.0. My Toolchain Root Location is pointing to /opt/poky/2.0 and my sysroot is pointing at /opt/poky/2.0/sysroots/x86-poky-linux.
I was able to compile a "Hello, world" program using this enviromnent, but with a larger project I hit errors during the Build Project step.
Here's the relevant part of my config.log:
Configured with: /home/presslertj/poky/build/tmp/work-shared/gcc-5.2.0-r0/gcc-5.2.0/configure --build=x86_64-linux --host=x86_64-pokysdk-linux --target=i586-poky-linux --prefix=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr --exec_prefix=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr --bindir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux --sbindir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux --libexecdir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-poky-linux --datadir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/share --sysconfdir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/etc --sharedstatedir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/com --localstatedir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/var --libdir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/lib/i586-poky-linux --includedir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/include --oldincludedir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/include --infodir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/share/info --mandir=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/presslertj/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=i586-poky-linux- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/5.2.0 --with-build-time-tools=/home/presslertj/poky/build/tmp/sysroots/x86_64-linux/usr/i586-poky-linux/bin --with-sysroot=/not/exist --with-build-sysroot=/home/presslertj/poky/build/tmp/sysroots/piu --enable-targets=all --enable-poison-system-directories --with-mpfr=/home/presslertj/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-mpc=/home/presslertj/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --enable-nls --enable-__cxa_atexit
Thread model: posix
gcc version 5.2.0 (GCC)
configure:2971: $? = 0
configure:2960: i586-poky-linux-gcc -m32 -march=pentium-m --sysroot=/opt/poky/2.0/sysroots/x86-poky-linux -V >&5
i586-poky-linux-gcc: error: unrecognized command line option '-V'
i586-poky-linux-gcc: fatal error: no input files
compilation terminated.
configure:2971: $? = 1
configure:2960: i586-poky-linux-gcc -m32 -march=pentium-m --sysroot=/opt/poky/2.0/sysroots/x86-poky-linux -qversion >&5
i586-poky-linux-gcc: error: unrecognized command line option '-qversion'
i586-poky-linux-gcc: fatal error: no input files
compilation terminated.
configure:2971: $? = 1
configure:2991: checking whether the C compiler works
configure:3013: i586-poky-linux-gcc -m32 -march=pentium-m --sysroot=/opt/poky/2.0/sysroots/x86-poky-linux -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c >&5
configure:3017: $? = 0
configure:3065: result: yes
configure:3068: checking for C compiler default output file name
configure:3070: result: a.out
configure:3076: checking for suffix of executables
configure:3083: i586-poky-linux-gcc -m32 -march=pentium-m --sysroot=/opt/poky/2.0/sysroots/x86-poky-linux -o conftest -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c >&5
configure:3087: $? = 0
configure:3109: result:
configure:3131: checking whether we are cross compiling
configure:3139: i586-poky-linux-gcc -m32 -march=pentium-m --sysroot=/opt/poky/2.0/sysroots/x86-poky-linux -o conftest -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c >&5
configure:3143: $? = 0
configure:3150: ./conftest
/home/presslertj/workspace/HMM/configure: ./conftest: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
configure:3154: $? = 126
configure:3161: error: in `/home/presslertj/workspace/HMM':
configure:3163: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
I think the most important line of this might be:
/home/presslertj/workspace/HMM/configure: ./conftest: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
Which looks to me like it's looking in the wrong place for ld-linux.so.2.
Also, when running build, Eclipse's terminal spits out the following lines:
ENV key HOST_CC_ARCH is NULL
ENV key TOOLCHAIN_OPTIONS is NULL
ENV key SELECTED_OPTIMIZATION is NULL
ENV key TARGET_ARCH is NULL
ENV key OECMAKE_C_LINK_FLAGS is NULL
ENV key OECMAKE_CXX_LINK_FLAGS is NULL
ENV key STAGING_DIR_HOST is NULL
ENV key STAGING_DIR_NATIVE is NULL
ENV key CROSS_DIR is NULL
ENV key OECMAKE_EXTRA_ROOT_PATH is NULL
ENV key EXTERNAL_TOOLCHAIN is NULL
ENV key STAGING_DATADIR is NULL
I'm guessing that one of these variables needs to be specified so that ld-linux.so.2 is found but I don't know which, and I feel like I might've missed some critical step. What is causing this error? Have I misconfigured my environment?
As read in How to fix /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory:
This will happen only on 64 bit systems, the cause is the fact that 32
bit libraries are missing from the system, so you can easily fix this
issue by installing the 32 bit libraries on your system.
So if you encounter this error /lib/ld-linux.so.2: bad ELF
interpreter: No such file or directory this is how you can fix it:
To fix it:
On any RPM based distribution (CentOS/RedHat/Fedora/Suse/Mandriva):
yum -y install glibc.i686
On any DEB based distribution (Debian/Ubuntu/Mint/Crunchbang):
apt-get update
apt-get install ia32-libs
I'm trying to use MinGW-W64 instead of MinGW in Codelite. When I compile simple "hello, world" project it's all right. But when I try to link some libraries, I get a strange linker error. Project with exactly same settings compiles by MinGW with any problems. There are build output for both variants:
MinGW GCC 4.8.1
`C:\Windows\system32\cmd.exe /C D:/apps/mingw/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
====0 errors, 0 warnings====`
MinGW-W64 GCC 5.2.0
`C:\Windows\system32\cmd.exe /C D:/apps/mingw-w64/mingw32/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw-w64/mingw32/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw-w64/mingw32/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
g++.exe: error: #code.txt -L./lib/: No such file or directory
mingw32-make.exe[1]: *** [bin/code] Error 1
code.mk:78: recipe for target 'bin/code' failed
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
====1 errors, 0 warnings====`
This looks like a bug in your toolchain and not in CodeLite.
There is a space between the "#code.text" and -L./lib and for some reason g++ does not see it...
I put my money on the mingw32-make tool. You can tell CodeLite to use the mingw32-make.exe from the 4.8.1 version (which worked): settings->build settings->compilers->[YOUR COMPILER NAME]->Make
Another option is to disable the option that tells CodeLite to generate Makefile that passes the object list via file to the compiler:
Settings->Build Settings->compilers->[YOUR COMPILER NAME]->Advanced tab and uncheck the option: pass object list to the linker via file
Lately i too have found the similar problem. Later i was able to figure out the issue. We just to need to go to the project settings under change makefile generator default to codelite makefile generator i think that will work.
I m trying to build using gcc arm cross compiler and i get following error
Building file: ../src/application.c
Invoking: GCC C Compiler
arm-linux-gcc -O3 -Wall -c -I -fmessage-length=0 -MMD -MP -MF"src/application.d" -MT"src/application.d" -o "src/application.o" "../src/application.c"
/bin/sh: 1: arm-linux-gcc: not found
i also check my path setting and i had proper valid path to the arm-linux-gcc
and also linux "which" command gives the correct path of arm-linux-gcc..
could some one let me know what i am doing wrong..?
i figured it out,very silly mistake. i was trying to run 32-bit binary on a 64-bit system.
I have some trouble with crosscompiling C++ program which takes advantage of openMP library. I am using Linux Ubuntu 12.04 LTS. I want to obtain executable file runnable on Windows.
I have no problem with compiling my program with OMP with regular g++ command:
g++ a.cpp b.cpp -o OMPres -pg -O3 -I./CBLAS/include -L./ -lcblas
Also when I try crosscompilation without OMP, everything runs perfectly fine:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o res.exe -l gfortran -static
But when I try to crosscompile it with OMP using following command:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I get this error:
a.cpp:41:17: fatal error: omp.h: No such file or directory
compilation terminated.
I found where omp.h file is located on my disk, and added the path to the command. After executing it:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I got another error: x86_64-w64-mingw32-g++: error: libgomp.spec: No such file or directory
As I also have this file on the disk I tried to copy it in various places and finaly it worked when I copied it directly into the directory where compilation takes place. Then it produced another error:
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgomp
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lrt
collect2: ld returned 1 exit status
I don't have a good understanding of how compilers exactly work. I tried to update all mingw-w64 compilers that I could find with apt-cache search but nothing helped. I have no idea what more I can do :(.
First, #nmaier is completely correct in that the Ubuntu x86_64-w64-mingw32 toolchain is crippled, and that you can rebuild the toolchain yourself.
I, however, suggest that you use MXE, which saves you the time of manually compiling gcc and every dependency of it. The steps below should be enough for your purpose:
# Get MXE
git clone https://github.com/mxe/mxe.git && cd mxe
# Settings
cat <<EOF > settings.mk
MXE_TARGETS := x86_64-w64-mingw32.static
JOBS := 4
EOF
# Build gcc, libgomp, blas, and cblas. It will take a while
make -j2 libgomp cblas
# Add toolchain to PATH
# See http://htmlpreview.github.io/?https://github.com/mxe/mxe/blob/master/index.html#tutorial step 4
export PATH=`pwd`/usr/bin:$PATH
# You don't need -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a
# because headers and libraries are installed to standard location and
# I already used `-lcblas -lblas`.
x86_64-w64-mingw32-g++ a.cpp b.cpp -fopenmp -O3 -o res.exe -lcblas -lblas -lgfortran -lquadmath
Your x86_64-w64-mingw32 toolchain appears to have been build without libgomp.
You could check your supplier/distribution if it there additional or variant packages that have libgomp.
Or switch to a different supplier/distribution.
Or you could rebuild (or build in the first place) a cross gcc with --enable-libgomp. This is kinda the hard way.
PS:
Adding paths that do not correspond with your platform, like -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include, is a bad idea in general, and will most certainly fail... This kinda creates a Franken-compiler.