New build system ready for testing
chrisj at rtems.org
Tue Sep 15 06:57:32 UTC 2020
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):
>>>> ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio':
>>>> undefined reference to `PHYS_TO_VM_PAGE'
>>>> 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 \
>>>> Adding your patch from ages ago to libbsd works to solve that:
>>>> 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
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.
>> LibBSD can then create and install it's own .pc file:
>> $ cat /opt/rtems/6/lib/pkgconfig/bsd.pc
>> 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 ...
> 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.
Pretty simple is relative. A pkg-config file removes the needs to update these
flags if something changes. I would rather see us have files for all libraries
even if they are simple. This way the simple and hard are all handled the same way.
More information about the devel