rtems-libbsd build error

Christian Mauderer list at c-mauderer.de
Mon Apr 1 17:26:47 UTC 2019

Am 01.04.19 um 16:38 schrieb Vijay Kumar Banerjee:
> Doing a make for all, I'm getting this not found error ...

Just a note: The make for all shouldn't be necessary. But if you do it
please have a very detailed look at what is changed. It should be
nothing except the things you added.

> ............
> make: freebsd-org/contrib/libpcap/gen_version_header.sh: Command not found
> make: *** [Makefile.todo:277: freebsd/contrib/libpcap/pcap_version.h]
> Error 127
> .............

Seems that this build step has been eliminated from libpcap. The
pcap_version.h isn't included anywhere anymore. Maybe you can create and
test a patch that removes the header
freebsd/contrib/libpcap/pcap_version.h and the build step in Makefile.todo?

> But it successefully builds the .m files into .c and .h files (I haven't
> edited the Makefile yet).
> after the make, if I try to ./waf it, it gives this error ...
> ==========
> In file included from ../../rtemsbsd/include/machine/bus.h:781:0,
>                  from ../../rtemsbsd/include/machine/_bus.h:1,
>                  from ../../freebsd/sys/sys/bus.h:35,
>                  from ../../rtemsbsd/local/usb_if.c:17:
> ../../rtemsbsd/include/machine/bus_dma.h:44:2: error: #error "the header
> file <machine/rtems-bsd-kernel-space.h> must be included first"
>  #error "the header file <machine/rtems-bsd-kernel-space.h> must be
> included first"
>   ^~~~~
> ../../rtemsbsd/local/usb_if.c:18:10: fatal error: usb_if.h: No such file
> or directory
>  #include "usb_if.h"
>           ^~~~~~~~~~
> compilation terminated.

Please use `./waf -j1` to get only one error message. There are two
messages mixed here.

> ==========
> it seems like it's not changing it to #include
> <rtems/bsd/local/usb_if.h>. Is it supposed 
> to be done manually by opening each file or am I missing a script?  
That should be done by the freebsd-to-rtems.py script when you import
the files. If it doesn't change these, you either have called it in a
wrong way or the script has a bug.

> On Mon, Apr 1, 2019 at 7:32 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>     Am 01.04.19 um 15:29 schrieb Vijay Kumar Banerjee:
>     [...] (I removed some of the discussion to make it more readable)
>     >
>     >     If you use the fb and framebuffer headers from RTEMS, you will
>     get an
>     >     RTEMS interface. The RTEMS based console code will work fine.
>     But it
>     >     might would be the solution where more work is necessary to
>     port other
>     >     applications or libraries. It seems that we have some libs
>     already (like
>     >     nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I
>     would be OK
>     >     with that.
>     >
>     >     The other alternative would be to use the FreeBSD code that
>     does the
>     >     same. I'm not sure whether they call it framebuffer or
>     something else.
>     >     But I would expect that there is something similar. In that
>     case it
>     >     might would be simpler to port graphics libraries that already
>     work on
>     >     FreeBSD.
>     >
>     >     Both ways could be nice. I'm really not sure which one I would
>     prefer.
>     >     The first one is better integrated into the existing RTEMS
>     ecosystem.
>     >     The second one promises a wider world. So either take the one that
>     >     interests you more or just use the one that looks simpler ;-)
>     >
>     > I will take the 2nd path and use the codes from freebsd fb. In the
>     > forked branch 
>     > I have imported them along with the iic souce files just to make sure
>     > that it builds.
>     > I have also added the driver references in the nexus-device.h 
>     > I have a few questions/doubts before moving on to creating a fresh
>     > branch to import
>     > the file cleanly so that porting work can be started.
>     >
>     > There are a lot of files that are imported and out of them some
>     were .m
>     > files that 
>     > I built manually with the awk scripts and imported using the
>     libbsd.py .
>     > It seems like those 
>     > will need a cleanup and will need to be added to the Makefile.todo
>     (?)
>     Most likely Makefile.todo is currently the right place. Also in long
>     term it should move to waf. But that's out of the scope of your project.
>     >
>     > Will the whole thing be one big patch? or will it be done in chunks of
>     > the subdirectory
>     > like videomode headers and souce imported in one patch, fb in
>     another ?
>     I think I already have made a note at your proposal: I would suggest to
>     split it up in smaller functional blocks. That even allows to merge
>     small parts during the GSoC instead of having one big block at the end.
>     But please note that all parts should be useful and every commit in
>     libbsd (and in RTEMS) must be compilable. Otherwise (useful) tools like
>     `git bisect` won't work.
>     So if you have functional groups: Split it up. If a big block is
>     necessary because the small parts can't work on their own: Keep it in
>     one import + one port commit.
>     >
>     [...]

More information about the devel mailing list