install path for libcpu

Hill, Jeff johill at lanl.gov
Tue Oct 2 21:57:50 UTC 2012


Thanks for that explanation.

> If librtemscpu.a is installed properly in
> ${prefix}/${target}/${BSP}/lib/
 
This appears to be the root of the problem. 

I see this file:
${prefix}/${target}/lib/librtemcpu.a

I don't see this file:
${prefix}/${target}/${BSP}/lib/librtemcpu.a

Removing ${prefix}/${target}/lib/librtemcpu.a and then 
rebuilding everything doesn't improve my situation.

So presumably this issue, installation of librtemcpu.a on the 
wrong path, is caused by some configuration mistake in the 
BSP? I will have a look, but any hints are greatly 
appreciated :-)

Jeff

> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Sent: Tuesday, October 02, 2012 3:18 PM
> To: Hill, Jeff
> Cc: rtems-users at rtems.org
> Subject: Re: install path for libcpu
> 
> On 10/2/2012 4:09 PM, Hill, Jeff wrote:
> >> Did you do a make install after you built RTEMS?
> >>
> >> Did you set RTEMS_MAKEFILE_PATH to reflect the
> ${prefix}/${target}/${BSP}?
> > Yes, my build script does perform both of the above actions,
> > each time that it runs.
> Something is subtly wrong. You shouldn't have to edit
> gcc-target-default.cfg and I think that's where the dependency is
> coming from.
> 
> librtemscpu.a is normally picked up by adding -qrtems to the gcc
> command line. This dependency is built into gcc if the target is
> built to include gcc/config/rtems.h. This is from gcc/config.gcc
> for the mips target.
> 
> mips*-*-rtems*)
>          tm_file="elfos.h newlib-stdint.h ${tm_file} mips/elf.h
> mips/rtems.h rtems.h"
>          tmake_file="mips/t-elf t-rtems mips/t-rtems"
>          ;;
> 
> Notice that tm_file references rtems.h which corresponds to
> gcc/config/rtems.h
> and that file has this:
> 
> #undef LIB_SPEC
> #define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
> "%{!nostdlib: %{qrtems: --start-group \
>   -lrtemsbsp -lrtemscpu \
>   -lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
> 
> Which is how the -lrtemscpu is picked up.
> 
> If librtemscpu.a is installed properly in
> ${prefix}/${target}/${BSP}/lib, then
> the gcc built-in library specification should let you find it.
> 
> Time to check what gcc is doing.
> 
> 
> >> -----Original Message-----
> >> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> >> Sent: Tuesday, October 02, 2012 3:03 PM
> >> To: Hill, Jeff
> >> Cc: rtems-users at rtems.org
> >> Subject: Re: install path for libcpu
> >>
> >> On 10/2/2012 3:40 PM, Hill, Jeff wrote:
> >>>> Normally the BSP specifically lists which components
> >>>> from libcpu it wants. Those get included in the librtemsbsp.a.
> >>>>
> >>>> ...
> >>>>
> >>>> libcpu objects p--- are not directly installed. The .h files are.
> >>> I am still confused; from my perspective it appears that some
> >>> of the RTEMS applications, for example netdemo, appear to
> >>> explicitly reference librtemscpu.a?
> >>>
> >>> Making all in netdemo
> >>> make[1]: Entering directory `/home/hill/nios2-rtems/rtems/rtems-
> >> git/network-demos/netdemo'
> >>> make[1]: *** No rule to make target
> >>> `/home/hill/install/rtems-4.11-/nios2-rtems/altera-sys-
> >> config/lib/librtemscpu.a',
> >>>    needed by `o-optimize/netdemo.exe'.  Stop.
> >> Hold on... librtemscpu.a is NOT libcpu. It is cpukit.
> >>
> >> Did you do a make install after you built RTEMS?
> >>
> >> Did you set RTEMS_MAKEFILE_PATH to reflect the
> ${prefix}/${target}/${BSP}?
> >>
> >> --joel
> >>> Thanks for your assistance,
> >>>
> >>> Jeff
> >>>
> >>>> -----Original Message-----
> >>>> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> >>>> Sent: Tuesday, October 02, 2012 8:56 AM
> >>>> To: Hill, Jeff
> >>>> Cc: rtems-users at rtems.org
> >>>> Subject: Re: install path for libcpu
> >>>>
> >>>> On 10/02/2012 09:38 AM, Hill, Jeff wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Maybe someone will have a quick answer for an RTEMS build system
> >> mystery
> >>>>> that I currently don't understand. I have had to make this change in
> >>>>> c/src/make/compilers/gcc-target-default.cfg but I don't understand
> >>>>> why others do not experience the same issue?
> >>>>>
> >>>>> After:
> >>>>>
> >>>>> LINK_FILES =\
> >>>>>        $(CONSTRUCTOR) \
> >>>>>        $(OBJS) \
> >>>>>        $(PROJECT_RELEASE)/lib/librtemsbsp$(LIBSUFFIX_VA) \
> >>>>>        $(PROJECT_RELEASE)/../lib/librtemscpu$(LIBSUFFIX_VA)
> >>>>>
> >>>>> Before:
> >>>>>
> >>>>> LINK_FILES =\
> >>>>>        $(CONSTRUCTOR) \
> >>>>>        $(OBJS) \
> >>>>>        $(PROJECT_RELEASE)/lib/librtemsbsp$(LIBSUFFIX_VA) \
> >>>>>        $(PROJECT_RELEASE)/lib/librtemscpu$(LIBSUFFIX_VA)
> >>>>>
> >>>>> If I don't make this change then application codes like the
> >>>>> netdemo will not build with the original RTEMS build system.
> >>>>>
> >>>>> This is probably self inflicted, and no-doubt has something
> >>>>> to do with install path for libcpu. I see this issue in all
> >>>>> versions of RTEMS, with the Nios2 BSP.
> >>>> Normally the BSP specifically lists which components
> >>>> from libcpu it wants. Those get included in the librtemsbsp.a.
> >>>> Here is a fragment from sparc/erc32/Makefile.am to pick up
> >>>> the libcpu components that BSP wants:
> >>>>
> >>>> libbsp_a_LIBADD  = \
> >>>>        ../../../libcpu/@RTEMS_CPU@/access.rel \
> >>>>        ../../../libcpu/@RTEMS_CPU@/cache.rel \
> >>>>        ../../../libcpu/@RTEMS_CPU@/reg_win.rel \
> >>>>        ../../../libcpu/@RTEMS_CPU@/syscall.rel
> >>>>
> >>>>
> >>>> libcpu objects are not directly installed. The .h files are.
> >>>>> Thanks,
> >>>>>
> >>>>> Jeff
> >>>>> ______________________________________________________
> >>>>> Jeffrey O. Hill           Email        johill at lanl.gov
> >>>>> LANL MS H820              Voice        505 665 1831
> >>>>> Los Alamos NM 87545 USA   FAX          505 665 5107
> >>>>>
> >>>>> Message content: Correspondence
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> rtems-users mailing list
> >>>>> rtems-users at rtems.org
> >>>>> http://www.rtems.org/mailman/listinfo/rtems-users
> >>>> --
> >>>> Joel Sherrill, Ph.D.             Director of Research&   Development
> >>>> joel.sherrill at OARcorp.com        On-Line Applications Research
> >>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >>>>        Support Available             (256) 722-9985
> >>>>
> >>
> >> --
> >> Joel Sherrill, Ph.D.             Director of Research&  Development
> >> joel.sherrill at OARcorp.com        On-Line Applications Research
> >> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >>       Support Available             (256) 722-9985
> 
> 
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>      Support Available             (256) 722-9985





More information about the users mailing list