New build system ready for testing

[Chris Johns]

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