undefined reference to 'main'
Chris Johns
cjohns at cybertec.com.au
Sat Jan 10 01:02:21 UTC 2004
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
More information about the users
mailing list