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.
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.
I was following the osdev barebones tutorial and successfully created boot.o and linker.ld, but ran into a problem when the i686-elf-gcc compiler didn't create the kernel.o file. It gave no errors. This is what I ran to compile it:
i686-elf-gcc -c kernel.c -o kernel.o -std=gnu99 -ffreestanding -O2 -Wall -Wextra
But no matter how many times I do it, there's still no kernel.o!
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.
I am using the Boost library in Unix, GCC. I read the following topic: Boost static linking and added -static to my Makefile. However, this does not work.
Here is my Makefile:
all: nbbo
nbbo: nbbo.o reader.o
g++ -static -O3 -ffast-math -funroll-loops -ansi -pedantic-errors -L/usr/lib -lboost_filesystem -lboost_serialization -lboost_iostreams -lz -I /usr/include/boost -o nbbo nbbo.o reader.o
nbbo.o: nbbo.cpp
g++ -static -O3 -ffast-math -funroll-loops -ansi -pedantic-errors -I /usr/include/boost -c -o nbbo.o nbbo.cpp
reader.o: reader.cc reader.h
g++ -static -O3 -ffast-math -funroll-loops -ansi -pedantic-errors -I /usr/include/boost -c -o reader.o reader.cc
clean:
rm *.o
And here is the error message:
nbbo.o: In function `__tcf_10':
nbbo.cpp:(.text+0x3d9): undefined reference to `boost::serialization::extended_type_info::key_unregister() const'
nbbo.cpp:(.text+0x3e3): undefined reference to `boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister()'
nbbo.cpp:(.text+0x3fb): undefined reference to `boost::serialization::typeid_system::extended_type_info_typeid_0::~extended_type_info_typeid_0()'
etc
Which "UNIX" are you using? Using the -static flag should work fine on linux. But not on OSX. On OSX you have to remove the static flag and give the complete path to the library in order to link statically. I dont know how this would work on other "UNIXes"
eg.
g++ ..... /path/to/your/lib.a ... -o ..
When I compile my program I get compiler warnings. I have been trying to fix them for a while now.
This is how I compile:
c++ -MM -MF obj/src/prog.d -MP -MT obj/src/prog.o -Wall -Wextra -c -g -Iinc src/prog.cpp
This is the warning I get:
clang: warning: argument unused during compilation: '-MF obj/src/prog.d'
I used to compile it without warnings before apple switched to clang. right now c++ is just a symbolic link to clang.
I was wondering if smbd had the same kind of issue?
Any ideas?
Thanks
hmm... it seems like it is a bug(or feature): link.
But I think I found a work-around, instead of using MF to specify the output file, I just redirect it to the file like this:
c++ -MM > obj/src/prog.d -MP -MT obj/src/prog.o -Wall -Wextra -c -g -Iinc src/prog.cpp