undefined reference to 'main'

[Chris Johns]

Mark Mussetter wrote:
> Hello Everyone,
> 
> I'm having problems building a demo called nxscribble for microwindows 
> running on RTEMS running on a motorola 5272.  The build progresses fine 
> until the I get the following error about an undefined reference to 'main':
> 
> <SNIP>
> /opt/rtems-4.6/bin/m68k-rtems-gcc   -I. -I../../include -Wall 
> -Wno-unused -m5200 -g -O2 
> -B/rtems/build-4.6.0pre5-cfv2_66/m68k-rtems/cfv2_66/lib/ -specs 
> bsp_specs -qrtems  -L../../lib nxscribble.o scribwidget.o hre_api.o 
> li_recognizer.o bitvector.o matrix.o sc.o util.o -o ../../bin/nxscribble 
> ../../lib/libnano-X.a ../../lib/libmwengine.a ../../lib/libmwdrivers.a 
> ../../lib/libmwfonts.a  -lm
> 
> /rtems/build-4.6.0pre5-cfv2_66/m68k-rtems/cfv2_66/lib/librtemscpu.a(dummy.o)(.data+0x2c): 
> undefined reference to `main'
> <END SNIP>
> 
> I looked at the source for dummy.c to see where it was trying to 
> reference 'main' and found that it has a prototype as follows:
> int main( int, char **, char ** );
> 
> It also has the following line a little later in the file:
> #define CONFIGURE_INIT_TASK_ENTRY_POINT (void *)main
> 

Main will be called without the prototype arguments defined. The 
parameters will be the classic RTEMS task ones.

> We have our own 'main' function in 'nxscribble.c' but 'dummy.c' seems to 
> be getting in the way.  We noticed that the prototype in 'dummy.c' 
> didn't match our main declaration.  In 'nxscribble.c' main was "int 
> main( int argc, char **argv )", so we changed it to "int main( int argc, 
> char **argv, char **env )" to match 'dummy.c'.  However, this didn't help.
> 
> Can someone please point us in the right direction?
> 

I do not know which BSP you are using and cannot find it in the RTEMS 
source tree. I do not think having the label 'main' as an init task 
entry point is a such a good idea. I would expect the C standard 
parameters and this is not what happens.

If you wish to have main as the entry point then the following may help.

My BSPs (which are stand alone using a multilib RTEMS) expect the 
application to provide 'main' as the entry point. Main is called with 
RTEMS running and static C++ constructors already run and C++ static 
destructor's handler hooked onto the atexit chain.

To do this I have a configuration.c file that uses the confdefs.h header 
to setup the RTEMS configuration tables. The confdefs.h file is 
extremely useful. The BSP defines a single init task called 
'rtems_premain' that is defined in a file called main.c. This file also 
provides a 'boot_card'. It is almost the same as the one is the shared 
directory of libbsp. The difference is mine calls 
'rtems_initialize_executive_late' in 'boot_card' and catches control in 
'rtems_premain'. The 'rtems_premain' then creates the command line 
options, prints a little RTEMS banner (a must IMO :-)), hooks the C++ 
static destructor handler to the atexit chain, runs the C++ constructors 
(_init) then calls 'main'.

-- 
  Chris Johns, cjohns at cybertec . com . au