Linking application and BSP

[Joel Sherrill]

"Michael P. Collins on korat" wrote:
> 
> Earlier, I wrote:
> 
> >>   - The linker complains about "start.o" not being found.  I've
> >>     tried adding "$INSTALL_POINT/<bsp>/lib/start.o" to the list
> >>     of linked objects, but this doesn't work.  A symlink from that
> >>     file to the local directory does work; I haven't been able to
> >>     determine where the reference to a local "start.o" is coming
> >>     from.
> 
> And Joel replied:
> 
> > Did you do a "make install"?  And did you set RTEMS_MAKEFILE_PATH to
> > point to the install point.  If you are using RPMs, then it would
> > likely be something like /opt/rtems/MYBSP.
> 
>   I built RTEMS from source, and use "bit_rtems" to build the BSP.
> I've got a tarfile which contains all my BSP files, along with the
> "make/custom/<bsp>.cfg" files.  After untarring the distribution
> files, I add my tarfile.  At that point, I run "bit_rtems".
> INSTALL_RTEMS is set to yes in "user.cfg", and when "bit_rtems"
> completes, I have the expected files in "/usr/local/rtems/<bsp>".
> (INSTALL_POINT set to "/usr/local/rtems" in "user.cfg".)  So I
> never do a "make install" directly, but this appears to be done
> as part of "bit_rtems".

OK.

>   Looking more carefully at my 4.0 configuration, I had a link
> from "<bsp>/lib/start.o" to my application-build directory, so
> that was apparently something I've been doing all along.  Looking
> further, I don't see "start.o" in any of the libraries.  Is this
> typical?

No.  It sounds like possibily your bsp_specs does not have a %s
on the start.o or the bsp_specs is not properly constructed
somehow.  If it is in <bsp>/lib/start.o, then it is also at the
install point and thus your link rule SHOULD pick it up.

More than likely, simply copying the gen68360's bsp_specs will
fix things for you.
 
> > Another possibility is that you built the debug variant of
> > RTEMS but your bsp_specs does not quite have -qrtems_debug support.
> 
>   This turns out to be the case, and I've since changed that entry
> in "user.cfg".  I also copied bsp_specs over from efi332.

OK.  It looks OK.  TUrn on the -v on gcc to see what is linking.

> >>   I presume the the last item in the list pertains to the lack of
> >> filesystem support for my BSP.  How should I go about linking so I
> >> don't see those errors?
> 
> > NO problem with your BSP.  You are not using confdefs.h to
> > instantiate the configuration information.  Look at the way
> > hello uses confdefs.h.
> 
>   The change I made to resolve this problem was to add
> "#define CONFIGURE_INIT" to my "init.c" file.  I previously had
> "#define TEST_INIT" in that file, which is what "hello/init.c" had
> in the 4.0 days.

confdefs.h has wandered from test fixture to application space.  The
cleanup between 4.0 and 4.5 was noticeable.
 
>   I'm getting there.  I can now link everything together successfully,
> although I still wonder if there's a way to link "start.o" without
> it having to be in the local directory.

>   Thanks for the help.
>                                         -- MC --

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985