Re: New build system ready for testing
On 16/9/20 4:45 pm, Karel Gardas wrote: > Looks great, but on submit attempt I've been welcome by "Akismet says > content is spam" and I guess I solved math exercise well... I am sorry, I have no idea why that would happen. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 9/16/20 3:16 AM, Chris Johns wrote: > On 15/9/20 5:36 pm, Sebastian Huber wrote: >> On 15/09/2020 09:32, Karel Gardas wrote: >> >>> On 9/15/20 9:28 AM, Sebastian Huber wrote: Maybe it is more practical if we add a table to a wiki page in which everyone can add the BSPs which were tested with the new build system. >>> I think this would be fantastic to have. >> An alternative would be to add it to the ticket as a comment. I can add a >> table >> to the ticket description and update the table based on the comments. > > A ticket is hard to account for the BSPs once checked. I have created a BSP > checklist table with some columns I think are useful. I hope this is OK: > > https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist Looks great, but on submit attempt I've been welcome by "Akismet says content is spam" and I guess I solved math exercise well... Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 16/9/20 12:21 pm, Gedare Bloom wrote: > Can you add a brief explanation of each column? I think I know, but I > don't want to assume. Yes that is a good idea. I will do it now. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On Tue, Sep 15, 2020 at 7:16 PM Chris Johns wrote: > > On 15/9/20 5:36 pm, Sebastian Huber wrote: > > On 15/09/2020 09:32, Karel Gardas wrote: > > > >> On 9/15/20 9:28 AM, Sebastian Huber wrote: > >>> Maybe it is more practical if we add a table to a wiki page in which > >>> everyone can add the BSPs which were tested with the new build system. > >> I think this would be fantastic to have. > > An alternative would be to add it to the ticket as a comment. I can add a > > table > > to the ticket description and update the table based on the comments. > > A ticket is hard to account for the BSPs once checked. I have created a BSP > checklist table with some columns I think are useful. I hope this is OK: > > https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist > Can you add a brief explanation of each column? I think I know, but I don't want to assume. > Chris > ___ > 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: New build system ready for testing
On 15/9/20 5:36 pm, Sebastian Huber wrote: > On 15/09/2020 09:32, Karel Gardas wrote: > >> On 9/15/20 9:28 AM, Sebastian Huber wrote: >>> Maybe it is more practical if we add a table to a wiki page in which >>> everyone can add the BSPs which were tested with the new build system. >> I think this would be fantastic to have. > An alternative would be to add it to the ticket as a comment. I can add a > table > to the ticket description and update the table based on the comments. A ticket is hard to account for the BSPs once checked. I have created a BSP checklist table with some columns I think are useful. I hope this is OK: https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 16/9/20 2:03 am, Kinsey Moore wrote: > I had assumed that the old build system would be removed when the new build > system got added, but that obviously didn't happen. Will it eventually be > removed after a transition period is over or will they both exist and be > maintained going forward? I do not expect to see any changes to the autoconf and automake build system. The autotools build system will be removed once we are happy things have been checked and are OK _and_ the supporting ecosystem tools know how to build the kernel with waf. The 6.1 release will not have a configure script or Makefile at the top level. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: New build system ready for testing
This is great news as the AArch64 work I've been doing was built on your waf branch and now I can rebase on to mainline code. I had assumed that the old build system would be removed when the new build system got added, but that obviously didn't happen. Will it eventually be removed after a transition period is over or will they both exist and be maintained going forward? Kinsey -Original Message- From: devel On Behalf Of Sebastian Huber Sent: Monday, September 14, 2020 02:08 To: RTEMS Subject: New build system ready for testing Hello, I checked in the new build system today. Now is a good time to test your favourite BSP if it still works. You find the user oriented documentation of build system here: https://docs.rtems.org/branches/master/user/bld/index.html The documentation for RTEMS maintainers is here: https://docs.rtems.org/branches/master/eng/build-system.html How to check the new build system for a particular BSP? 1. Build the BSP with all tests enabled. 2. Run the tests and compare the results with the old build system. Ideally use the RTEMS Tester to run the tests and report them to the RTEMS Project. 3. Check if all BSP options are available (./waf bsp_defaults). Check the type and values of the BSP options. 4. Check the linker command file. 5. Check the compiler machine flags. 6. Install the BSP and build your third-party libraries and applications with it. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ 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: New build system ready for testing
On 9/15/20 9:36 AM, Sebastian Huber wrote: > On 15/09/2020 09:32, Karel Gardas wrote: > >> On 9/15/20 9:28 AM, Sebastian Huber wrote: >>> Maybe it is more practical if we add a table to a wiki page in which >>> everyone can add the BSPs which were tested with the new build system. >> I think this would be fantastic to have. > An alternative would be to add it to the ticket as a comment. I can add > a table to the ticket description and update the table based on the > comments. Whatever suites you best, but table is IMHO right way to go on this. Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 15/09/2020 09:32, Karel Gardas wrote: On 9/15/20 9:28 AM, Sebastian Huber wrote: Maybe it is more practical if we add a table to a wiki page in which everyone can add the BSPs which were tested with the new build system. I think this would be fantastic to have. An alternative would be to add it to the ticket as a comment. I can add a table to the ticket description and update the table based on the comments. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 9/15/20 9:28 AM, Sebastian Huber wrote: > Maybe it is more practical if we add a table to a wiki page in which > everyone can add the BSPs which were tested with the new build system. I think this would be fantastic to have. Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 15/09/2020 09:09, Chris Johns wrote: On 14/9/20 5:07 pm, Sebastian Huber wrote: I checked in the new build system today. Now is a good time to test your favourite BSP if it still works. Thank you for this work. It is really great. Do you have any thoughts on how we track which BSPs have been looked at and are OK? What do I need to do to say a BSP is OK? In theory we could use the same approach as we did using the old build system. We report the test results and collect the information to document the tiers. Maybe it is more practical if we add a table to a wiki page in which everyone can add the BSPs which were tested with the new build system. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 14/9/20 5:07 pm, Sebastian Huber wrote: > I checked in the new build system today. Now is a good time to test your > favourite BSP if it still works. Thank you for this work. It is really great. Do you have any thoughts on how we track which BSPs have been looked at and are OK? What do I need to do to say a BSP is OK? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 15/9/20 4:31 pm, Sebastian Huber wrote: > On 15/09/2020 00:46, Chris Johns wrote: > >> On 15/9/20 1:18 am, Sebastian Huber wrote: >>> Hello Christian, >>> >>> On 14/09/2020 14:23, Christian Mauderer wrote: Hello Sebastian, I get a linker error when I try to build libbsd for BBB (with a buildset that builds everything but netipsec): - /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio': /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1813: undefined reference to `PHYS_TO_VM_PAGE' /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1814: undefined reference to `uiomove_fromphys' collect2: error: ld returned 1 exit status - Configure line for libbsd is: ./waf configure \ --prefix=/home/EB/christian_m/Projekte/rtems-bbb//install/rtems/6 \ --rtems-bsps=arm/beagleboneblack \ --buildset=/home/EB/christian_m/Projekte/rtems-bbb//build/src/noipsec.ini \ --enable-warnings \ --optimization=2 \ --rtems-version=6 Adding your patch from ages ago to libbsd works to solve that: https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7.patch But you haven't applied it to the libbsd master. So I assume that there is a better workaround for that problem? What's the correct solution? >>> thanks for testing. Apparently, I tested with this patch applied. This is an >>> open issue. Chris was not happy with this patch. >> Yes that is correct. Patching libbsd this way solves the issue for us, the >> RTEMS >> developers, however the same problem remains for applications linking to >> libbsd. > > No, we have two different kind of flags which play a role here: > > 1. Flags for the compiler: -fdata-sections -ffunction-sections > > 2. A flag for the linker: -Wl,--gc-sections > > I linker flag is required by the application if it links to -lbsd. The > compiler > flags are required to build libbsd itself, but they are NOT required to build > the application objects or other libraries. Thanks, this makes sense. We still need to address the exporting of the link flag. waf_libbsd.py is not the place for the flags. This should be added to libbsd.py in the defaults. waf_libbsd.py is part of build engine and should not have any settings. I can have a look after my posted changes are pushed. The self.data in waf_libbsd.py is a bit of a beast these days. > The linker flag part of the patch could be removed. It just makes libbsd > requirements a bit more explicit. Let me have a look at this. Thinking about this now we also need to indicate if the "flag" is to be exported. The section compilers do not but the link option does. >> Requiring users copy these flags into application specific build systems is >> fragile. Just look at the issues EPICS has updating to RTEMS 5. We need to >> do a >> better of job of handling these settings. As a result I do not support the >> easy fix. >> >>> I think the -fdata-sections and -ffunction-sections flags should not be >>> exported >>> by the pkg-config file of the build system since these are optimization >>> flags >>> which affect the code generation. However, for libbsd these flags are >>> mandatory >>> and should be enforced by a library-specific rule. >> I am not sure what you mean when you say .. enforcing a library specific >> rule? >> We can only lead by providing robust interfaces that do not change with each >> version of RTEMS yet let us evolve RTEMS. >> >> I believe rtems.git needs to export flags for libraries we use via pkgconfig. >> For example we could use variables for this: >> >> pkgconfig /somewhere/i386-rtems6-pc686.pc --variable libbsd-cflags > To use a library, you don't need CFLAGS. You need LDFLAGS and maybe CPPFLAGS > if > it has special include paths. Depends on the include paths used and this means the prefix. If there are no special flags pkg-config will return an empty string. >> The variable name `libbsd-cflags` could be something less specific to libbsd >> like `sections-cflags` or something better. We can have other variables like >> a >> base address, a u-boot mkimage set of flags, etc. I would like to see these >> grow >> over time to address the difficult area of exporting architecture and BSP >> specific settings. > Yes, I also think that pkg-config should be the interface for applications to > get these values. Great. >> >> LibBSD
Re: New build system ready for testing
On 15/09/2020 00:46, Chris Johns wrote: On 15/9/20 1:18 am, Sebastian Huber wrote: Hello Christian, On 14/09/2020 14:23, Christian Mauderer wrote: Hello Sebastian, I get a linker error when I try to build libbsd for BBB (with a buildset that builds everything but netipsec): - /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio': /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1813: undefined reference to `PHYS_TO_VM_PAGE' /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1814: undefined reference to `uiomove_fromphys' collect2: error: ld returned 1 exit status - Configure line for libbsd is: ./waf configure \ --prefix=/home/EB/christian_m/Projekte/rtems-bbb//install/rtems/6 \ --rtems-bsps=arm/beagleboneblack \ --buildset=/home/EB/christian_m/Projekte/rtems-bbb//build/src/noipsec.ini \ --enable-warnings \ --optimization=2 \ --rtems-version=6 Adding your patch from ages ago to libbsd works to solve that: https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7.patch But you haven't applied it to the libbsd master. So I assume that there is a better workaround for that problem? What's the correct solution? thanks for testing. Apparently, I tested with this patch applied. This is an open issue. Chris was not happy with this patch. Yes that is correct. Patching libbsd this way solves the issue for us, the RTEMS developers, however the same problem remains for applications linking to libbsd. No, we have two different kind of flags which play a role here: 1. Flags for the compiler: -fdata-sections -ffunction-sections 2. A flag for the linker: -Wl,--gc-sections I linker flag is required by the application if it links to -lbsd. The compiler flags are required to build libbsd itself, but they are NOT required to build the application objects or other libraries. The linker flag part of the patch could be removed. It just makes libbsd requirements a bit more explicit. Requiring users copy these flags into application specific build systems is fragile. Just look at the issues EPICS has updating to RTEMS 5. We need to do a better of job of handling these settings. As a result I do not support the easy fix. I think the -fdata-sections and -ffunction-sections flags should not be exported by the pkg-config file of the build system since these are optimization flags which affect the code generation. However, for libbsd these flags are mandatory and should be enforced by a library-specific rule. I am not sure what you mean when you say .. enforcing a library specific rule? We can only lead by providing robust interfaces that do not change with each version of RTEMS yet let us evolve RTEMS. I believe rtems.git needs to export flags for libraries we use via pkgconfig. For example we could use variables for this: pkgconfig /somewhere/i386-rtems6-pc686.pc --variable libbsd-cflags To use a library, you don't need CFLAGS. You need LDFLAGS and maybe CPPFLAGS if it has special include paths. The variable name `libbsd-cflags` could be something less specific to libbsd like `sections-cflags` or something better. We can have other variables like a base address, a u-boot mkimage set of flags, etc. I would like to see these grow over time to address the difficult area of exporting architecture and BSP specific settings. Yes, I also think that pkg-config should be the interface for applications to get these values. LibBSD can then create and install it's own .pc file: $ cat /opt/rtems/6/lib/pkgconfig/bsd.pc prefix=/opt/rtems/6 exec_prefix=/opt/rtems/6 libdir=/opt/tems/6/lib includedir=/opt/rtems/6/include Name: libbsd Version: 5.1.0 Description: RTEMS LibBSD URL: httpis:/git.rtems.org/rtems-libbsd.git Libs: -lbsd Cflags: -fdata-sections -ffunction-sections An application can then: $ pkg-config /opt/rtems/6/lib/pkgconfig/i386-rtems6-pc686.pc --cflags --libs bsd -qrtems -B/opt/rtems/6/i386-rtems6/lib/ -B/opt/rtems/6/i386-rtems6/pc686/lib/ --specs bsp_specs -mtune=pentiumpro -march=pentium -O2 -g -ffunction-sections -Wnested-externs -fdata-sections -ffunction-sections -lbsd I am sure the .pc files could be better than the quick hack shown here. I think a suitable design and model could be established that can be used for all 3rd party libraries. Note, rtems_waf has been using .pc files for years waiting for the RTEMS .pc support to evolve into a copmlete interface ... https://git.rtems.org/rtems_waf/tree/rtems.py#n794 Yes, the libbsd could install its own pkg-config file although using
Re: New build system ready for testing
On 15/9/20 1:18 am, Sebastian Huber wrote: > Hello Christian, > > On 14/09/2020 14:23, Christian Mauderer wrote: >> Hello Sebastian, >> >> I get a linker error when I try to build libbsd for BBB (with a buildset that >> builds everything but netipsec): >> >> - >> /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: >> ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio': >> /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1813: >> undefined reference to `PHYS_TO_VM_PAGE' >> /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: >> /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1814: >> undefined reference to `uiomove_fromphys' >> collect2: error: ld returned 1 exit status >> - >> >> Configure line for libbsd is: >> >> ./waf configure \ >> --prefix=/home/EB/christian_m/Projekte/rtems-bbb//install/rtems/6 \ >> --rtems-bsps=arm/beagleboneblack \ >> >> --buildset=/home/EB/christian_m/Projekte/rtems-bbb//build/src/noipsec.ini \ >> --enable-warnings \ >> --optimization=2 \ >> --rtems-version=6 >> >> Adding your patch from ages ago to libbsd works to solve that: >> >> >> https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7.patch >> >> >> But you haven't applied it to the libbsd master. So I assume that there is a >> better workaround for that problem? What's the correct solution? > > thanks for testing. Apparently, I tested with this patch applied. This is an > open issue. Chris was not happy with this patch. Yes that is correct. Patching libbsd this way solves the issue for us, the RTEMS developers, however the same problem remains for applications linking to libbsd. Requiring users copy these flags into application specific build systems is fragile. Just look at the issues EPICS has updating to RTEMS 5. We need to do a better of job of handling these settings. As a result I do not support the easy fix. > I think the -fdata-sections and -ffunction-sections flags should not be > exported > by the pkg-config file of the build system since these are optimization flags > which affect the code generation. However, for libbsd these flags are > mandatory > and should be enforced by a library-specific rule. I am not sure what you mean when you say .. enforcing a library specific rule? We can only lead by providing robust interfaces that do not change with each version of RTEMS yet let us evolve RTEMS. I believe rtems.git needs to export flags for libraries we use via pkgconfig. For example we could use variables for this: pkgconfig /somewhere/i386-rtems6-pc686.pc --variable libbsd-cflags The variable name `libbsd-cflags` could be something less specific to libbsd like `sections-cflags` or something better. We can have other variables like a base address, a u-boot mkimage set of flags, etc. I would like to see these grow over time to address the difficult area of exporting architecture and BSP specific settings. LibBSD can then create and install it's own .pc file: $ cat /opt/rtems/6/lib/pkgconfig/bsd.pc prefix=/opt/rtems/6 exec_prefix=/opt/rtems/6 libdir=/opt/tems/6/lib includedir=/opt/rtems/6/include Name: libbsd Version: 5.1.0 Description: RTEMS LibBSD URL: httpis:/git.rtems.org/rtems-libbsd.git Libs: -lbsd Cflags: -fdata-sections -ffunction-sections An application can then: $ pkg-config /opt/rtems/6/lib/pkgconfig/i386-rtems6-pc686.pc --cflags --libs bsd -qrtems -B/opt/rtems/6/i386-rtems6/lib/ -B/opt/rtems/6/i386-rtems6/pc686/lib/ --specs bsp_specs -mtune=pentiumpro -march=pentium -O2 -g -ffunction-sections -Wnested-externs -fdata-sections -ffunction-sections -lbsd I am sure the .pc files could be better than the quick hack shown here. I think a suitable design and model could be established that can be used for all 3rd party libraries. Note, rtems_waf has been using .pc files for years waiting for the RTEMS .pc support to evolve into a copmlete interface ... https://git.rtems.org/rtems_waf/tree/rtems.py#n794 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
Hello Christian, On 14/09/2020 14:23, Christian Mauderer wrote: Hello Sebastian, I get a linker error when I try to build libbsd for BBB (with a buildset that builds everything but netipsec): - /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio': /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1813: undefined reference to `PHYS_TO_VM_PAGE' /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1814: undefined reference to `uiomove_fromphys' collect2: error: ld returned 1 exit status - Configure line for libbsd is: ./waf configure \ --prefix=/home/EB/christian_m/Projekte/rtems-bbb//install/rtems/6 \ --rtems-bsps=arm/beagleboneblack \ --buildset=/home/EB/christian_m/Projekte/rtems-bbb//build/src/noipsec.ini \ --enable-warnings \ --optimization=2 \ --rtems-version=6 Adding your patch from ages ago to libbsd works to solve that: https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7.patch But you haven't applied it to the libbsd master. So I assume that there is a better workaround for that problem? What's the correct solution? thanks for testing. Apparently, I tested with this patch applied. This is an open issue. Chris was not happy with this patch. I think the -fdata-sections and -ffunction-sections flags should not be exported by the pkg-config file of the build system since these are optimization flags which affect the code generation. However, for libbsd these flags are mandatory and should be enforced by a library-specific rule. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
Hello Sebastian, I get a linker error when I try to build libbsd for BBB (with a buildset that builds everything but netipsec): - /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio': /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1813: undefined reference to `PHYS_TO_VM_PAGE' /home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld: /home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1814: undefined reference to `uiomove_fromphys' collect2: error: ld returned 1 exit status - Configure line for libbsd is: ./waf configure \ --prefix=/home/EB/christian_m/Projekte/rtems-bbb//install/rtems/6 \ --rtems-bsps=arm/beagleboneblack \ --buildset=/home/EB/christian_m/Projekte/rtems-bbb//build/src/noipsec.ini \ --enable-warnings \ --optimization=2 \ --rtems-version=6 Adding your patch from ages ago to libbsd works to solve that: https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7.patch But you haven't applied it to the libbsd master. So I assume that there is a better workaround for that problem? What's the correct solution? Best regards Christian On 14/09/2020 09:07, Sebastian Huber wrote: > Hello, > > I checked in the new build system today. Now is a good time to test your > favourite BSP if it still works. You find the user oriented > documentation of build system here: > > https://docs.rtems.org/branches/master/user/bld/index.html > > The documentation for RTEMS maintainers is here: > > https://docs.rtems.org/branches/master/eng/build-system.html > > How to check the new build system for a particular BSP? > > 1. Build the BSP with all tests enabled. > > 2. Run the tests and compare the results with the old build system. > Ideally use the RTEMS Tester to run the tests and report them to the > RTEMS Project. > > 3. Check if all BSP options are available (./waf bsp_defaults). Check > the type and values of the BSP options. > > 4. Check the linker command file. > > 5. Check the compiler machine flags. > > 6. Install the BSP and build your third-party libraries and applications > with it. > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
