54

I am porting an application from Solaris to Linux

The object files which are linked do not have a main() defined. But compilation and linking is done properly in Solaris and executable is generated. In Linux I get this error 

    /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'

My problem is, I cannot include new .c/.o files since its a huge application and has been running for years. How can I get rid of this error?

Code extractes of makefile:

RPCAPPN = api
LINK = cc 

    $(RPCAPPN)_server: $(RPCAPIOBJ)
            $(LINK) -g $(RPCAPIOBJ) -o $(RPCAPPN)_server $(IDALIBS) $(LIBS) $(ORALIBS) $(COMMONLIB) $(LIBAPI) $(CCLIB) $(THREADLIB) $(DBSERVERLIB) $(ENCLIB)
Blackforest
  • 1,009
  • 2
  • 11
  • 18
  • Simple: either you stop calling main or you define a main(^) Why did it work on solaris? Did it have special linker flags (link to shared object?) – wildplasser Jun 20 '12 at 09:46
  • but ctr1.o is an OS defined object file present in /usr/lib64. Hence calling main() cannot be changed. – Blackforest Jun 20 '12 at 09:50
  • It depends! If you use `boost`, then try @serup's [answer](https://stackoverflow.com/a/39889638/8691463), it works on me – Kevin Chou Apr 23 '19 at 13:05

8 Answers8

50

Try adding -nostartfiles to your linker options, i.e.

$(LINK) -nostartfiles -g ...

From the gcc documentation:

-nostartfiles
    Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.

This causes crt1.o not to be linked (it's normally linked by default) - normally only used when you implement your own _start code.

Paul R
  • 208,748
  • 37
  • 389
  • 560
  • 7
    depending on the issue, then this is not really a solution - I had similar problem when trying to make boost test project and adding this flag made everything worse – serup Oct 06 '16 at 06:55
  • 3
    It's not a good solution for me neither. I'm getting: "/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004562d0" among other many things after using this flag – m4l490n Nov 30 '18 at 20:37
  • @m4l490n Did the program work okay with this warning? For the command "gcc -Wall insertion_sort.c -nostartfiles -lpython2.7 -o insertion_sort", I also got similar warning "/usr/local/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004005d0". – vineeshvs Mar 27 '19 at 05:12
29

-shared link option must be used when you compile a .so

Kevin Panko
  • 8,356
  • 19
  • 50
  • 61
user2783604
  • 309
  • 3
  • 2
  • 6
    This actually helped me installing an R package that previously failed with the error above. – Thomas Jun 05 '14 at 12:46
  • 2
    Agreed; this also helped me get around a problem with compiling external functions for sqlite. – gregory Jun 03 '16 at 21:39
7

The issue for me was, I by mistake put int main() in a namespace. Make sure don't do that otherwise you will get this annoying link error.

Hope this helps anyone :)

Moshe Rabaev
  • 1,892
  • 16
  • 31
2

I had similar result when trying to build a new test project with boost, and it turned out that I was missing one declaration :

#define BOOST_TEST_MODULE <yourtestName>
serup
  • 3,676
  • 2
  • 30
  • 34
0

I had a similar result when compiling a Fortran program that had C++ components linked in. In my case, CMake failed to detect that Fortran should be used for the final linking. The messages returned by make then ended with 

[100%] Linking CXX executable myprogram
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
make[3]: *** [myprogram] Error 1
make[2]: *** [CMakeFiles/myprogram.dir/all] Error 2
make[1]: *** [CMakeFiles/myprogram.dir/rule] Error 2
make: *** [myprogram] Error 2

The solution was to add

set_target_properties(myprogram PROPERTIES LINKER_LANGUAGE Fortran)

to the CMakeLists.txt, so that make prints out:

[100%] Linking Fortran executable myprogram
[100%] Built target myprogram
Bastian
  • 901
  • 7
  • 23
0

I had this same problem when creating my c project, and I forgot to save my main.c file, so there was no main function.

Nailuj29
  • 750
  • 1
  • 10
  • 28
0

I had the same issue with a large CMake project, after I moved some functions from one code file to another. I deleted the build folder, recreated it and rebuilt. Then it worked.

Generally, with suddenly appearing linker errors, try completely deleting your build folder and rebuilding first. That can save you the headaches from trying to hunt down an error that actually simply shouldn't be there: There might be CMake cache variables floating around that have the wrong values, or something was renamed and not deleted, ...

RL-S
  • 734
  • 6
  • 21
0

I had the same issue as to OP but on on FreeBSD 13.1.

What solved the issue was simply adding:

int main()
{
}

Since the .cpp file was only an object file containing definitions and declarations using:

extern "C"
{
  <all definitions and declarations code goes here>
}

Every time I tried compiling this, the compiler kept throwing the same error as to OP.

So all I did was add an empty main() function all the way at the bottom and code compiled with no errors.

Max Dax
  • 49
  • 3