How do I find my program's main(...) function?

Question

I am currently porting a project with a few hundred code files and dependencies onto several third-party libraries to Mac Os. I've finally gotten to the point where the program compiles without warnings or errors, but it does not seem to execute my own main function.

Instead it seems to execute some other main function which seems to belong to a third party. This function writes some diagnostic-looking data to the console and exits afterwards:

(gdb) continue
Current language:  auto; currently c++
//
// This is an automatically generated file.
// Do not edit.
//

const unsigned short expTable[] =
{
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
...
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
};

Debugger stopped.
Program exited with status value:0.

I can't use the debugger to find out where this main function resides because, while the stack trace seems valid, gdb doesn't show me the correct line number and file name for each stack entry (See this unsolved question for details).

The search took several minutes to complete, but did not return any results.

My project is using SDL among other libraries, but I am award of SDL_Main() and the underlying problems and have built my project on top of a perfectly fine working SDL project template. So I am quite sure that my own main function is valid.

Do you have any idea what might be going wrong? I'm currently out of ideas on how to find and remove the rogue main function.

Thanks,

Adrian

EDIT: As I just found out, I made a mistake while searching file files with the string "This is an automatically generated". I just found several dozen files with the same string, all belonging to FreeImage, one of the third party libraries I am using. So, the problem seems to be related to FreeImage, but I am not still not sure how to proceed since I have compiled Freeimage as a library with the enclosed MacOs makefile and included only the library. I will try to rebuild a newer version of FreeImage and see it if that fixed my problem.

Answer 1

Could it be an initializer for a static object that fails before your main() is called?

Answer 2

Do you have several main in the binary? Try using nm on it. (it shouldn't be possible as ld won't link with duplicates, but go into the dynamical libs and look for _main there)

nm a.out | grep -5 _main

This should give 5 lines before and after any _main found in the binary a.out

If you have several, see the surrounding symbols for hints which parts they are in...

Next step can be to do the same on each dynamic lib that is used. To get a list of the used dynamic libraries use otool

otool -L a.out

Answer 3

I'm not sure how to find the other one, but you can specify your own entry point explicitly and make the other one unused. You can use the GNU linker ld -e option to set your entry point.

-e entry

--entry=entry

Use entry as the explicit symbol for beginning execution of your program, rather than the default entry point. If there is no sym- bol named entry, the linker will try to parse entry as a number, and use that as the entry address (the number will be interpreted in base 10; you may use a leading 0x for base 16, or a leading 0 for base 8).

For future readers, if you have this problem in Windows. The equivalent linker option is /ENTRY.

Answer 4

Did you try running your executable through nm? It might be able to give you some hints. I wouldn't think it'd be possible to link a program with more than one globally visible function named main(), not sure how that manages to happen.