New build system ready for testing

[Sebastian Huber]

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 an 
installed libbsd is pretty simple. You just have to add -lbsd and 
-Wl,--gc-sections. The -Wl,--gc-sections is already provided by the BSP 
pkg-config file.