Troubles linking an object file to a C file in a Makefile - c

I've been given an object file set.o* as well as the header file set.h. I need to run tests on the functions in the file I've created, main.c. I've written the following Makefile
all: main
main: main.c set.h set.o
clang -Wall -g main.c set.o -o main
clean:
rm main
This Makefile keeps giving me the error:
ld: warning: ignoring file set.o, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 )
Undefined symbols for architecture x86_64:
"_validateMemUse", referenced from:
_main in main-f6a155.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [main] Error 1
If anyone knows where I went wrong, a reply would be greatly appreciated :)

The error is quite clear, here cut down to the important statement with emphasis by me:
ld: warning: ignoring file set.o, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format
Apparently the file "set.o" was compiled for another target system, or is not an object file. In any case, the linker cannot recognize it and therefore is not able to link your "main.c" to it.
Get back to the person who gave you this file and ask for an object file for your Mac, or even better the source.
Note: Your Makefile is OK.

Related

Error while linking libraries: building for macOS-arm64 but attempting to link with file built for macOS-arm64

I compile the ffmpeg and compiler outputs the following errors.
ld: warning: ignoring file libavdevice/libavdevice.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file libavfilter/libavfilter.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file libswresample/libswresample.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file libswscale/libswscale.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file libavutil/libavutil.a, building for macOS-arm64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )
ld: warning: ignoring file libpostproc/libpostproc.a, building for macOS-arm64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )
ld: warning: ignoring file libavformat/libavformat.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file libavcodec/libavcodec.a, building for macOS-arm64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )
I don't understand why macOS-arm64 cannot link to macOS-arm64.
Shouldn't an arm64 object file link to arm64 static libraries?
I'm working on an M1 macbook, and configure the ffmpeg with the following commands.
../configure --cc=/usr/bin/clang --prefix=/opt/ffmpeg --enable-avisynth --enable-fontconfig --enable-gpl --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librubberband --enable-libwebp --enable-libx264 --enable-libx265 --enable-libzimg --enable-libzmq --enable-version3 --pkg-config-flags=--static --disable-ffplay --extra-cflags="-I/opt/homebrew/include" --extra-cxxflags="-I/opt/homebrew/include" --extra-ldflags="-L/opt/homebrew/lib"
The full output is here: https://pastebin.com/u9QNTitu
Looks like Clang (when invoked as gcc) does not like linking with static libraries made by GNU ar.
% echo "int main() { }" > a.c
% gcc -c a.c
% /opt/homebrew/opt/binutils/bin/ar rcs a.a a.o
% gcc a.a
ld: warning: ignoring file a.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
...
While, if you do the same with Apple's ar (and take care to delete a.a, created by binutils, first), it links correctly. The error message is just misleading in this case. This is why #Peng's answer is in the right direction. There is no need to actually remove binutils, just don't have it in your PATH when building ffmpeg, so the build will pick up the default ar.
If you use brew, maybe you should use brew uninstall binutils...
I was facing a similar error and switching node versions helped. I switched from 14 to 16.

How to fix " Undefined symbols for architecture x86_64 " in C?

I have a header file included in the main but when I compile the main, I have an error saying that the linker failed.
I tried to find the object files but I cannot find them.
I think the problem may come from my machine. I am kind of a beginner so I don't know how to solve this
When I try compiling my code I get this error:
Undefined symbols for architecture x86_64:
"_intClassic", referenced from:
_main in main-53b7e4.o
"_intQuadrature", referenced from:
_main in main-53b7e4.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
#zwol #JonathanLeffer I have 3 files in my project main.c, integral.h
and integral.c. integral.c contains the code of the functions
intClassic and intQuadrature that allow me to calculate different
types of integral. In integral.h I declared the functions and
structures I use. Finally in the main I included integral.h .
Also $ gcc -o output file1.o file2.o can this command help me ?
In the same directory as your files, try running the command
gcc main.c integral.c -o integral
This should take the 2 files and compile them into a program called ./integral

Can't compile a c project i got from my teacher. (mac)

So i got a makefile and when i run that i get this:
gcc -Wall -g -L. -DSTUDENT_MODE=1 -o lab2 lab2.c lab2_funcs.c advfuncs.o -lm
ld: warning: ignoring file advfuncs.o, file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x86_64): advfuncs.o
Undefined symbols for architecture x86_64:
"__array", referenced from:
_main in lab2-bdc822.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [all] Error 1
The makefile looks like this:
PROGRAM=lab2
SOURCES=lab2.c lab2_funcs.c
CFLAGS=-Wall -g -L.
all: $(SOURCES)
gcc $(CFLAGS) -DSTUDENT_MODE=1 -o $(PROGRAM) $(SOURCES) advfuncs.o -lm
#teacher: $(SOURCES)
# gcc $(CFLAGS) -DSTUDENT_MODE=0 -c advfuncs.c
# gcc $(CFLAGS) -o $(PROGRAM) $(SOURCES) advfuncs.o -lm
clean:
\rm -f lab2 lab2_funcs.o
I tried running this on eclipse on my windows machine but i get other errors. I even got a complete compiled version of the project by the teacher but i cant seem to run that either, i just get an error that i cant that binary file.

a contradictory result when checking an example of "Linking with external libraries"

I just started to learn gcc/g++ by reading "An introduction to GCC"
In chapter 3.1 the author showed an example of linking with external libraries and header files. The main source code uses 'gdbm.h' header (installed at /opt/gdbm-1.8.3/include/ in text book) file and the library ‘libgdbm.a’ (installed at /opt/gdbm-1.8.3/lib/ in text book). The process of linking with the library and header file is as follows:
Link to example screenshot
When I tried to repeat this, I got a contradictory result. When I used method 1 (in the example fails) which only includes header file path, the program can be compiled, however, when I used method 2 (in the example succeeds), I got an error, saying that
"ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1"
(this is my full command line and error message:)
userMacBook-Pro:03 user$gcc -Wall -I/usr/local/include dbmain.c -L/usr/local/lib dbmain.c -lgdbm
duplicate symbol _main in:
/var/folders/6_/09vfzzms7dq1d73vl4mwlxmh0000gn/T/dbmain-9d15f9.o
/var/folders/6_/09vfzzms7dq1d73vl4mwlxmh0000gn/T/dbmain-907e96.o
this is my command that succeeds:
userMacBook-Pro:03 user$ gcc -Wall -I/usr/local/include dbmain.c -lgdbm
userMacBook-Pro:03 user$ ./a.out
Storing key-value pair... done.
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Can anyone explain why this happens?
I don't know which platform the author uses, I just use mac OS X.
gcc -Wall -I/usr/local/include dbmain.c -L/usr/local/lib dbmain.c -lgdbm
The file dbmain.c is present twice on your command line. For this reason the main function is present twice.

Writing first c program in vi editor in cygwin

I [extremely] new to c programming and cygwin so thanks for being patient. I am using a PDF of Michael Vine's C programming for beginners and trying to enter and compile the first example.
Here is what i wrote in vi:
#include <stdio.h>
main ()
{
printf("\nHello World\n");
}
When I try to compile using gcc, I get two errors:
1) usr/lib/gcc/i686-pc-cygwin/3.4.4./... /bin/ld:new: file format not recognized; treating as linked script
2) [same path as above]/bin/ld:new:11: syntax error collect2: ld returned 1 exit status
I'm pretty sure the actual syntax I used in vi is correct (its straight out of an example) and the gcc command is also correct. Am I missing a package or is my path to cygwin screwed up? Anyone know what's going on with this?
GCC, for better or for worse, uses the filename you pass to it to figure out what operation to do - run the compiler, the assembler, or the linker, or some combination, for example. Since you named your source file new, GCC is assuming it's a compiled object and is trying to link it. Either rename it new.c or pass the -x c flag when compiling.
For future reference, a good way to debug funny business with the GCC compiler driver is to pass the -v flag. If you do so for your original command line you'll see that it just invokes the linker, skipping the compilation step. An example from my machine:
$ gcc -v new -o new.exe
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.4 -weak_reference_mismatches non-weak -o new.exe -lcrt1.10.6.o -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../.. -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../.. new -lSystem -lgcc -lSystem
ld: warning: ignoring file new, file was built for unsupported file format ( 0x20 0x23 0x69 0x6e 0x63 0x6c 0x75 0x64 0x65 0x20 0x3c 0x73 0x74 0x64 0x69 0x6f ) which is not the architecture being linked (x86_64): new
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
One basic syntax error:
' main(){ ... } '
In C/C++, your main function should be:
'int main(){ ... }'

Resources