Unable to compile Hello World - c

Sorry if this is a repeat question, but I couldn't find an answer that worked.
I'm writing a Hello World C program for the first time in a long time. I'm fairly certain the code is right, but it won't compile.
Running MAC OS 10.13.6 and I just downloaded XCode last week. The program compiles into an object file using
cc -c test.c -o test.o
without a problem. However, I can't create an executable using
cc test.o -o test
Here's the code:
#include <stdio.h>
int Main()
{
printf("Hello World");
return 0;
}
When I go to create the executable, I get
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
I'm guessing I need to add some compiler flags but can't figure out which ones.

It sounds like you are just starting out in your journey into c code. This is a great opportunity to learn about c, compiling, and linking.
What you have written can compile just fine into an object file (containing a function called Main()). However, to link into an executable that can run from your OS, you need to define an entry point which is assumed to be a function called main (case sensitive as John mentioned above).
Check out this resource: http://www.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html for an explanation of what the gcc compiler gets up to behind the scenes.
You just need to make a couple of small changes to get your code to work as expected:
#include <stdio.h>
int main(void) {
printf("Hello, world!\n");
return 0;
}
Main needs to be lowercase main.
While int main() will work, int main(void) is technically more accurate (see
void main(void) vs main())
You probably want a line new line after Hello, world!, so add the \n. (https://www.tutorialspoint.com/c_standard_library/c_function_printf.htm)

Related

Compiling without main function (MacOS)

So I am trying to compile ,link and run a program without the main function.This is the code:
#include <stdio.h>
#include <stdlib.h>
int my_main()
{
printf("Hello world!\n");
return 0;
}
void _start()
{
exit(my_main());
}
Tried to compile with the command : gcc -nostartfiles nomain.c . While it does compile and produces the a.out file on a Debian vm, I am unable to compile it in my macOS Catalina v10.15.2. I am using the latest version of gcc. The message I am receiving when trying to compile is :
Undefined symbols for architecture x86_64: "_main", referenced from:
implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
So far I have tried to change _start to start but still getting the same result. As I understand the compilation process is different depending on the OS.
Note: There is no problem I am trying to solve here , just curiosity.
Thank you in advance
On macOS 10.14.6 with Xcode 11.3, the code in the question compiles and links with the command:
clang -Wl,-e, -Wl,__start <Name of Your Source File>
The resulting executable appears to work. However, since it bypasses the startup code for the C environment, you should not expect that using routines from the C library or other C features will work properly.
Note that two underscores are needed before start in the above command because the source code contains one and another is added by the C compiler. If the code is changed to use start instead of _start, then the command would use one underscore:
clang -Wl,-e, -Wl,_start <Name of Your Source File>
The switches -Wl,-e, -Wl,_start pass -e _start to the linker, which tells it to use _start as the address of the initial code to execute. It is not clear to me why this bypasses the default loading of the C-run-time-startup object module, which also defines _start. I would have preferred to use a linker switch that tells it not to load that module, but I did not find one in the man page for ld. Experimentation suggests that, by default, ld loads the default object module, and it refers to main, which results in a link error, but, when -e _start is used, the linker sets the program’s _start symbol as the startup address and does not load the default object module.
I'm pretty sure you can compile any C-source without main().
The problem will be with the linker trying to create an executable, which won't work without main().

C compiler gcc gives linker command failed error [duplicate]

I'm getting the following error and can't for the life of me figure out what I'm doing wrong.
$ gcc main.c -o main
Undefined symbols:
"_wtf", referenced from:
_main in ccu2Qr2V.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
main.c:
#include <stdio.h>
#include "wtf.h"
main(){
wtf();
}
wtf.h:
void wtf();
wtf.c:
void wtf(){
printf("I never see the light of day.");
}
Now, if I include the entire function in the header file instead of just the signature, it complies fine so I know wtf.h is being included. Why doesn't the compiler see wtf.c? Or am I missing something?
Regards.
You need to link wtf with your main. Easiest way to compile it together - gcc will link 'em for you, like this:
gcc main.c wtf.c -o main
Longer way (separate compilation of wtf):
gcc -c wtf.c
gcc main.c wtf.o -o main
Even longer (separate compilation and linking)
gcc -c wtf.c
gcc -c main.c
gcc main.o wtf.o -o main
Instead of last gcc call you can run ld directly with the same effect.
You are missing the fact that merely including a header doesn't tell the compiler anything about where the actual implementation (the definitions) of the things declared in the header are.
They could be in a C file next to the one doing the include, they could come from a pre-compiled static link library, or a dynamic library loaded by the system linker when reading your executable, or they could come at run-time user programmer-controlled explicit dynamic loading (the dlopen() family of function in Linux, for instance).
C is not like Java, there is no implicit rule that just because a C file includes a certain header, the compiler should also do something to "magically" find the implementation of the things declared in the header. You need to tell it.

Undefined reference to WinMain#16 when using SDL

I've been having a lot of trouble getting everything working so that I can start developing on Windows, as apposed to Linux, which is what I normally use when coding. I'm having a rather bizarre issue when trying to compile an SDL program. As soon as I include the SDL library, the program refuses to compile, giving me this error:
c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../libmingw32.a<main.o>: In function 'main':
C:\MinGW\msys\1.0\src\mingwrt/../mingw/main.c:73: undefined reference to 'WinMain#16'
collect2: ld returned 1 exist status
I am using MinGW on console.
To give an example, using
gcc -o test main.c
This compiles fine:
#include <stdio.h>
#include <stdlib.h>
int main(int argv, char **argc)
{
printf("Hello, world!\n");
return 0;
}
But as soon as I add #include (even without any SDL functions being called) I get the error mentioned above
Using:
gcc -o test main.c -lSDL
This fails to compile:
#include <stdio.h>
#include <stdlib.h>
#include <SDL/SDL.h>
int main(int argv, char **argc)
{
printf("Hello, world!\n");
return 0;
}
Any help would be greatly appreciated! I read that this was a common issue for people who forget to have a main function, but obviously that's not my issue. I also heard that WinMain is the main function used when dealing with Windows graphical programs, but that's never been an issue for me in the past when I used to develop in Windows more.
I did a little bit of searching for some more information on this error, and I found this page which includes the following informaion:
The only trick in getting this to compile now is to add the include path (eg: -I../SDL/include), the linker path (eg: -L../SDL/lib), and then finally adding the libraries themselves in the right order. Use:
-lmingw32 -lSDLmain -lSDL
Also, don't forget to add the -mwindows flag, if your IDE doesn't add it automatically (in addition to whatever other libraries you want to link). If you don't put them in the right order, you'll get a linker error complaining about the missing symbol WinMain#16.
Try recompiling with those flags above and see whether that makes a difference.

C Problem with Compiler?

I just started learning C, and wrote my hello world program:
#include <stdio.h>
main()
{
printf("Hello World");
return 0;
}
When I run the code, I get a really long error:
Apple Mach-O Linker (id) Error
Ld /Users/Solomon/Library/Developer/Xcode/DerivedData/CProj-cwosspupvengheeaapmkrhxbxjvk/Build/Products/Debug/CProj normal x86_64
cd /Users/Solomon/Desktop/C/CProj
setenv MACOSX_DEPLOYMENT_TARGET 10.7
/Developer/usr/bin/clang -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk -L/Users/Solomon/Library/Developer/Xcode/DerivedData/CProj-cwosspupvengheeaapmkrhxbxjvk/Build/Products/Debug -F/Users/Solomon/Library/Developer/Xcode/DerivedData/CProj-cwosspupvengheeaapmkrhxbxjvk/Build/Products/Debug -filelist /Users/Solomon/Library/Developer/Xcode/DerivedData/CProj-cwosspupvengheeaapmkrhxbxjvk/Build/Intermediates/CProj.build/Debug/CProj.build/Objects-normal/x86_64/CProj.LinkFileList -mmacosx-version-min=10.7 -o /Users/Solomon/Library/Developer/Xcode/DerivedData/CProj-cwosspupvengheeaapmkrhxbxjvk/Build/Products/Debug/CProj
ld: duplicate symbol _main in /Users/Solomon/Library/Developer/Xcode/DerivedData/CProj-cwosspupvengheeaapmkrhxbxjvk/Build/Intermediates/CProj.build/Debug/CProj.build/Objects-normal/x86_64/helloworld.o and /Users/Solomon/Library/Developer/Xcode/DerivedData/CProj-cwosspupvengheeaapmkrhxbxjvk/Build/Intermediates/CProj.build/Debug/CProj.build/Objects-normal/x86_64/main.o for architecture x86_64
Command /Developer/usr/bin/clang failed with exit code 1
I am running xCode
Should I reinstall DevTools?
have you tried
int main() or even int main(int argc, char**argv) ?
The error message indicates that the symbol _main (which refers to the main() function) is defined twice, once in helloworld.o and once in main.o.
It's likely that you have two source files, helloworld.c and main.c, in the same project, and that both define a function named main.
You can only have one main function in a program. Removing one of those two source files (and the associated object file) from your Xcode project should fix the problem. (I haven't used Xcode myself; perhaps someone else can tell you how to do that, if it's not obvious.)
(And the correct definition is int main(void), not the old-style main(), but I don't think that's related to the symptom you're seeing.)
There are a couple of stackoverflow questions that could be closely related to yours:
Xcode duplicate symbol _main
Xcode, Duplicate symbol _main

Undefined symbols error when using a header file

I'm getting the following error and can't for the life of me figure out what I'm doing wrong.
$ gcc main.c -o main
Undefined symbols:
"_wtf", referenced from:
_main in ccu2Qr2V.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
main.c:
#include <stdio.h>
#include "wtf.h"
main(){
wtf();
}
wtf.h:
void wtf();
wtf.c:
void wtf(){
printf("I never see the light of day.");
}
Now, if I include the entire function in the header file instead of just the signature, it complies fine so I know wtf.h is being included. Why doesn't the compiler see wtf.c? Or am I missing something?
Regards.
You need to link wtf with your main. Easiest way to compile it together - gcc will link 'em for you, like this:
gcc main.c wtf.c -o main
Longer way (separate compilation of wtf):
gcc -c wtf.c
gcc main.c wtf.o -o main
Even longer (separate compilation and linking)
gcc -c wtf.c
gcc -c main.c
gcc main.o wtf.o -o main
Instead of last gcc call you can run ld directly with the same effect.
You are missing the fact that merely including a header doesn't tell the compiler anything about where the actual implementation (the definitions) of the things declared in the header are.
They could be in a C file next to the one doing the include, they could come from a pre-compiled static link library, or a dynamic library loaded by the system linker when reading your executable, or they could come at run-time user programmer-controlled explicit dynamic loading (the dlopen() family of function in Linux, for instance).
C is not like Java, there is no implicit rule that just because a C file includes a certain header, the compiler should also do something to "magically" find the implementation of the things declared in the header. You need to tell it.

Resources