ARM bsp warnings ( shared/abort.c vs. shared/simple_abort.c )
There are two warnings in the raspberry pi BSP due to the lack of prototypes in simple_abort.c the rtl22xx BSP has the same warnings because it also uses simple_abort.c. Many of the other ARM BSPs use abort.c, which has prototypes for the two functions. The two functions in simple_abort.c and abort.c are nearly the same. Does anyone know why there is a simple_abort.c ? The potential fixes include: 1. removing simple_abort.c and have the Raspberry Pi and rtl22xx BSPs use abort.c or 2. simply putting the prototypes in simple_abort.c to take care of the warnings. Alan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: ARM bsp warnings ( shared/abort.c vs. shared/simple_abort.c )
On Sat, Nov 1, 2014 at 1:12 PM, Alan Cudmore wrote: > There are two warnings in the raspberry pi BSP due to the lack of prototypes > in simple_abort.c > the rtl22xx BSP has the same warnings because it also uses simple_abort.c. > > Many of the other ARM BSPs use abort.c, which has prototypes for the two > functions. > > The two functions in simple_abort.c and abort.c are nearly the same. > > Does anyone know why there is a simple_abort.c ? > > The potential fixes include: > 1. removing simple_abort.c and have the Raspberry Pi and rtl22xx BSPs use > abort.c or > 2. simply putting the prototypes in simple_abort.c to take care of the > warnings. > I prefer #1. I also would like to see the prototypes in abort.c go away. > Alan > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: ARM bsp warnings ( shared/abort.c vs. shared/simple_abort.c )
On 11/1/2014 1:38 PM, Gedare Bloom wrote: On Sat, Nov 1, 2014 at 1:12 PM, Alan Cudmore wrote: There are two warnings in the raspberry pi BSP due to the lack of prototypes in simple_abort.c the rtl22xx BSP has the same warnings because it also uses simple_abort.c. Many of the other ARM BSPs use abort.c, which has prototypes for the two functions. The two functions in simple_abort.c and abort.c are nearly the same. Does anyone know why there is a simple_abort.c ? The potential fixes include: 1. removing simple_abort.c and have the Raspberry Pi and rtl22xx BSPs use abort.c or 2. simply putting the prototypes in simple_abort.c to take care of the warnings. I prefer #1. I also would like to see the prototypes in abort.c go away. OK. It looks like the difference is that simple_abort.c uses less memory for the ARM CPUs that are very limited. I must have based the original Pi BSP on a BSP that used simple_abort.c instead of abort.c I can keep simple_abort.c if we feel that the savings are still needed. At this point only the rtl22xx BSP would use it. As for the prototypes, I can create a header. Should it go in libbsp/arm/shared/include or just in libbsp/arm/shared/abort? For example, I see that libbsp/arm/shared/uart has a uart.h. Also, if we keep simple_abort.c, it looks like both files could use the same header, since the defines and prototypes are the same. Alan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Sb-check and libz
Hi I know we have discussed this before but even if GCC were fixed to detect the missing library, you still get a long way into the build before it dies. I checked the source and didn't see any examples of checking for libraries. What can or should we do to improve.the user experience? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Sb-check and libz
On 2/11/2014 9:11 am, Joel Sherrill wrote: I know we have discussed this before but even if GCC were fixed to detect the missing library, you still get a long way into the build before it dies. I checked the source and didn't see any examples of checking for libraries. What can or should we do to improve.the user experience? It would be nice. Lowering the bar is an important part of the process. There are a couple of possible paths. One is to extend the per host support to check for a standard set of packages that host operating system needs installed. The other is to attempt to detect the library. The RSB currently supports detecting pkgconfig details for libraries. The qemu build in bare shows how this is done. The issue here is having this work in a uniform way across all hosts, ie a base install libz may not have a pkgconfig file. I just do not know. The other way is to add general support to check for libraries or headers with a compile test. You could include the waf code into the RSB and then use it to run the tests. I am not sure this is something we run each build. It depends on the time it takes. Adding per host os package detection is Python code and needs a user for each packaging system to provide patches. There should be a class per packaging system and then instances in the host specific host detection code. The list of packages needs to a configuration file as the possible list can change and expand as new things are added to the RSB and it may need to be keyed on the version of the OS. The advantage of this method is the user is given a list of packages needing to be installed. The disadvantage is users needing to install all required packages some of which they do not need. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
