Opened on 12/24/17 at 04:03:35
Closed on 01/02/18 at 06:23:05
#3266 closed defect (duplicate)
cpukit/libpci references BSP headers.
Reported by: | Chris Johns | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 5.1 |
Component: | lib | Version: | 5 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description
On the no-preinstall
branch of https://git.rtems.org/chrisj/rtems.git/ the build fails with:
sparc-rtems5-gcc --pipe -DHAVE_CONFIG_H -I.. -I/opt/work/chris/rtems/kernel/bsps/beagleboneblack/sparc-rtems5/c/erc32/include -I/opt/work/chris/rtems/kernel/rtems.git/cpukit/include -I/opt/work/chris/rtems/kernel/rtems.git/cpukit/score/cpu/sparc/include -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -MT pci_access.o -MD -MP -MF $depbase.Tpo -c -o pci_access.o /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libpci/pci_access.c &&\ mv -f $depbase.Tpo $depbase.Po In file included from /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/pci.h:23:0, from /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libpci/pci_access.c:10: /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/pci/access.h:16:10: fatal error: libcpu/byteorder.h: No such file or directory #include <libcpu/byteorder.h> ^~~~~~~~~~~~~~~~~~~~
This header is found under:
$ find . -name byteorder.h ./bsps/powerpc/include/libcpu/byteorder.h ./bsps/sparc/include/libcpu/byteorder.h ./bsps/i386/include/libcpu/byteorder.h
Change History (4)
comment:1 follow-up: 2 Changed on 12/24/17 at 20:09:09 by Joel Sherrill
comment:2 Changed on 12/26/17 at 21:59:42 by Chris Johns
Replying to Joel Sherrill:
Is there anything in the implementations that is BSP, not architecture, specific? They could be moved to cpukit if we have confidence they can be implemented always that way.
Or they can be real methods provided by the bsl
Sorry I do not know.
comment:4 Changed on 01/02/18 at 06:23:05 by Sebastian Huber
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
Is there anything in the implementations that is BSP, not architecture, specific? They could be moved to cpukit if we have confidence they can be implemented always that way.
Or they can be real methods provided by the bsl