SPARC BSPs Fail to Build rtems-libbsd
joel.sherrill at oarcorp.com
Wed May 27 01:30:39 UTC 2015
On May 26, 2015 8:21:10 PM CDT, Chris Johns <chrisj at rtems.org> wrote:
>On 27/05/2015 11:00 am, Joel Sherrill wrote:
>> On May 26, 2015 7:51:18 PM CDT, Chris Johns <chrisj at rtems.org> wrote:
>>> On 27/05/2015 8:14 am, Joel Sherrill wrote:
>>>> It looks the PCI API change has resulted in rtems-libbsd not
>>>> building for SPARC. Any ideas?
>>> The code unconditionally assumed all BSPs provided PCI support and
>>> installed "rtems/pci.h" header. I have just posted a patch that adds
>>> conditional support the waf build of rtems-libbsd so the LEON3 BSP
>> Is this really a mistake on the libpci side? Shouldn't it install the
>header as rtems/pci.h?
>If there is no PCI bus why should the header be installed ? It is a
>simple why for users and external packages to know if PCI is supported.
>If you add the header do you need to add the calls as well ?
Not arguing that. Just saying the other targets install the shared PCI header file as rtems/pci.h. if it is an enhanced compatible api, then it should be in the same place.
The support libraries can compile but if there is no PCI on the board, then the PCI drivers will never get linked. So dead code in the library but that's no big deal. Cpukit just needs to be consistent and this has one architecture install a .h file in a unique place. It is wrong.
More information about the devel