I'm trying to compile a c++ program and I am having some issues. In particular, when I use x86_64-w64-mingw32-gcc as my compiler, it complains half way through my compilation saying "tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized".
Here is my makefile (not mine, I'm trying to adapt this makefile to a cygwin environment) https://pastebin.com/vgnVYJUL
Here is the console output when I run make:
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver.cpp.o src/libfastms/solver/solver.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_base.cpp.o src/libfastms/solver/solver_base.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_host.cpp.o src/libfastms/solver/solver_host.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/has_cuda.cpp.o src/libfastms/util/has_cuda.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/image_mat.cpp.o src/libfastms/util/image_mat.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
ld -r -o tmp/src/libfastms/libfastms.o tmp/src/libfastms/solver/solver.cpp.o tmp/src/libfastms/solver/solver_base.cpp.o tmp/src/libfastms/solver/solver_host.cpp.o tmp/src/libfastms/util/has_cuda.cpp.o tmp/src/libfastms/util/image_mat.cpp.o
tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized
Makefile:167: recipe for target 'tmp/src/libfastms/libfastms.o' failed
make: *** [tmp/src/libfastms/libfastms.o] Error 1
Some other notes:
I don't have this problem when I compile with g++ (only seems to be minGW)
A common solution to this problem is to clean the directory of residual object files. This does not work.
Another common reason for this is trying to compile .h files. Obviously I am not doing this.
Thanks in advance.
You are compiling your object files with a 64-bit compiler driver, w64-mingw32-gcc,
and with -m64 you are explicitly directing it to generate 64-bit code (unnecessarily,
as that is its default). But you are linking with a 32-bit linker that does not
understand 64-bit object files.
This is happening because in your makefile you are, unusually, invoking ld
explicitly for your incremental solver linkage:
COMMAND_LINK_SOLVER=ld -r -o $# $^
rather than delegating linkage to your compiler driver in the usual way, and
a 32-bit ld from a different toolchain is being found in your PATH before
the 64-bit one belonging to your mingw-w64 toolchain.
To avoid this, invoke the linker via the compiler driver as normal, which for your
solver linkage means:
COMMAND_LINK_SOLVER=$(GXX) -Wl,-r -o $# $^
You can depend on w64-mingw32-gcc to invoke the ld that was installed with it.
There is no need to correct your main linkage as it is already done the right way.
Related
I'm trying to link a static library archive file (libx/libx.a) with a C code. The library requires 2 flags (-lx -lpthread). After linking the static library my ultimate goal is to create a shared library. I have the following Make file,
rsa-engine: rsa/rsa.c rsa/bignum.c rsa/aes.c rsa/x509parse.c rsa/pem.c
gcc -fPIC -o rsa/rsa.o -c rsa/rsa.c
gcc -fPIC -o rsa/bignum.o -c rsa/bignum.c
gcc -fPIC -o rsa/aes.o -c rsa/aes.c
gcc -fPIC -o rsa/x509parse.o -c rsa/x509parse.c
gcc -fPIC -o rsa/pem.o -c rsa/pem.c
gcc -fPIC rsa-engine.c libx/libx.a -L.libx/ -lx -lpthread -o rsa-engine.o
gcc -shared -o librsa_engine.so -lcrypto rsa-engine.o rsa/rsa.o rsa/bignum.o rsa/aes.o rsa/x509parse.o rsa/pem.o
clean:
rm -f *.o rsa/*.o *.so rsa-engine
After using the make command it produces the following output,
/usr/bin/ld: cannot find -lx
collect2: error: ld returned 1 exit status
Makefile:2: recipe for target 'rsa-engine' failed
make: *** [rsa-engine] Error 1
I found similar questions here. But that did not help. Seems like I can't make the link work. Any help with what I'm doing wrong?
I would like to achieve the same result generated by the following command,
CC := gcc
CFLAGS := -Wall -g -MD -O2 -I ../
LDFLAGS := -lx -lpthread
tests_files := hello
all: $(tests_files)
hello: hello.o ../libx/libx.a
$(CC) $(CFLAGS) -static $(<) -L../libx/ $(LDFLAGS) -o $(#)
It seems that your libx.a is located in libx, yet -L references .libx directory. Anyway, since you reference libx/libx.a directly, you may skip both -L.libx/ -lx and it should link just fine.
My Makefile:
helloworldlib.obj: helloworldlib.cpp
g++ -Wall -o helloworldlib.obj -c helloworldlib.cpp
helloworld.obj: source.cpp
g++ -Wall -o helloworld.obj -c source.cpp
helloworld.exe: source.cpp helloworld.obj
g++ -Wall -o helloworld.exe helloworld.obj helloworldlib.obj
I'm not sure what's wrong with this, when I run mingw32-make it only executes the first g++ -Wall -o helloworldlib.obj -c helloworldlib.cpp.
As far as I know this makefile is syntactically correct, mingw just doesn't seem to be able to find the other lines.
This is how make works. If no target is provided on the command line (e.g. mingw32-make helloworld.exe), by default it builds the first target defined in the file. See for instance: https://stackoverflow.com/a/2057716/2249356.
As a quick fix, you can just move the rule for helloworld.exe to the top of the file and then make will build all.
And, I think that the last rule is supposed to read
helloworld.exe: helloworld.obj helloworldlib.obj
g++ -Wall -o helloworld.exe helloworld.obj helloworldlib.obj
rather then with the source.cpp and its object code helloworld.obj as dependencies.
I have inherited a powerpc project that built fine under a SUSE linux environment back around 2008. My goal is to build the same thing in Linux Mint (v 17). The target processor is a powerpc, which is set in the environment variables, I believe. During the build on Mint linux, it produces the following error:
developer#Will-test-Mint-VM ~/temp/linux.apps $ make -f Makefile.runme
make DESTDIR=`pwd`/tmp install
make[1]: Entering directory `/home/developer/temp/linux.apps'
Making install in libStreamerControl
make[2]: Entering directory `/home/developer/temp/linux.apps/libStreamerControl'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c -o streamerControl.lo streamerControl.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c streamerControl.c -o streamerControl.o
gcc: error: unrecognized command line option '-meabi'
make[2]: *** [streamerControl.lo] Error 1
...
It is complaining about the -meabi option. I have installed/updated some packages that may be relevant (updated versions of eldk-5.6, automake, libtool, and powerpc-linux-gnu-gcc 4.8.2).
Specifically, I would like to know about the -meabi option. I didn't find a lot about it. What could be causing the compiler to not know what it is? I saw the output build from the SUSE setup, and it handled the -meabi option fine. Any suggestions?
Thanks,
Will
From your comment, it sounds like you're cross compiling here (ie., your build architecture is not the same as your host architecture). In this case, your (build) gcc won't recognise -meabi, as it's only valid for the host gcc.
So, you'll need to get your project building with the correct compiler for this to work. The method to do this will depend on the makefiles in your project. You've mentioned ARCH and CROSS_COMPILE, but these variables are specific to the Linux kernel's build system.
At a guess, your makefiles probably use some fairly standard variables to control the choice of compiler & toolchain, like CC, LD, etc. Try something like:
make -f Makefile.runme CC=powerpc-linux-gnu-gcc LD=powerpc-linux-gnu-ld
If your compile still fails, you may need to provide sources (or links to) your Makefiles.
I am new to Squirrel based scripting. Whenever I am trying to compile the program using the GCC compiler. I am getting the following error:
symbol(s) not found for architecture x86_64
I am trying to compile the code on a 64bit mac.
I am new so please excuse me if this is a really dumb question.
To solve the compilation you have to modify the Makefile under SQUIRREL3/sq/ by removing the -s flag from the g++ command.
Example:
sq64:
g++ -O2 -s -m64 -fno-exceptions -fno-rtti -D_SQ64 -o $(OUT) $(SRCS) $(INCZ) $(LIBZ) $(LIB)
becomes:
sq64:
g++ -O2 -m64 -fno-exceptions -fno-rtti -D_SQ64 -o $(OUT) $(SRCS) $(INCZ) $(LIBZ) $(LIB)
Hope it helps.
I'm trying to create a shared library with my gcc. It's a gcc for vxworks (thats probably the problem...).
I use the gcc as following:
./gcc -shared -B/path/to/gnutools/bin -o test.so test.c
Result:
/path/to/ld: -r and -shared may not be used together
collect2: ld returned 1 exit status
If I try the same with the linux gcc, there's no problem. So i guess the gcc for VxWorks automatically passes the -r (or -i, which is the same and results in the same) flag to the linker. Is there a way to suppress this?
Greetz
marty
PS: making it static is not really an alternative...
Try compile object file separately with -fPIC and then link:
gcc -Wall -fPIC -c -o test.o test.c
gcc -Wall -shared -o test.so test.o
Another suggestion is to use libtool (at least to figure out the correct flags).
A workaround may be to go directly with ld:
ld -shared -o test.so test.o -lc