Linking application and BSP

Michael P. Collins on korat mcollins at hawkeye.sps.mot.com
Wed Sep 20 21:59:57 UTC 2000


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".

  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?

> 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.

>>   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.

  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 --



More information about the users mailing list