[PATCH] build: Ensure mandatory compiler/linker flags

[Sebastian Huber]

On 14/07/2020 06:41, Chris Johns wrote:

> On 13/7/20 3:05 pm, Sebastian Huber wrote:
>> On 13/07/2020 02:09, Chris Johns wrote:
>>> On 8/7/20 9:37 pm, Sebastian Huber wrote:
>>>> On 08/07/2020 13:34, Chris Johns wrote:
>>>>
>>>>> Are these flags needed for all BSPs?
>>>> Yes, these flags are needed to build and use libbsd.
>>> Why not define them for all BSPs
>> In the new build system they are the default.
>>
>>> and for all applications?
>> I don't think we should mandate any optimization flags for applications. These
>> flags affect the code generation.
> But there is a class of application, ie linking with libbsd, which must have
> these flags as well.
If you link to libbsd, then you need the --gc-sections linker flags. You 
don't need the -fdata-sections and -ffunction-sections for the 
application code.
>
>>> What is special about libbsd that it needs these flags over any other type of
>>> application?
>> libbsd needs these flags since FreeBSD was not designed as a static library. In
>> addition, the porting to RTEMS is less intrusive and labour intensive using
>> these flags.
> Sure I understand this. Adding the flags to libbsd like this lets libbsd build
> it's tests, it however does not transfer through to a user application and this
> is what I would like to address. I see libbsd linking a test executable as the
> same use case a user has when linking a libbsd application.
Yes, but should we really export some optimization flags through the 
RTEMS BSP installation which are only required by libbsd?
>
>>>>> If so why add to here ...
>>>>>
>>>>> https://git.rtems.org/rtems/tree/c/src/bsp.pc.in
>>>> These are optimization flags. I thought the consensus was to export only ABI
>>>> relevant flags in the new build system.
>>> In CFLAGS yes. Pkgconfig files (.pc) support variables and I had always thought
>>> we define a number of RTEMS specific variables and these hold various flags or
>>> commands needed to handle other things, for example the options to mkimage. A
>>> user could then test for a variable and if present know this BSP does or has
>>> extra "what ever".
>> You mean some sort of recommended optimization flags? We should really define
>> what the pkg-config files should export so that I can implement this in the new
>> build system.
> The ABI flags are in CFLAGS. You could define a recommended optimisation set of
> flags as a variable. I was thinking of other things like the base addresses or
> size limits or even a post link command users can use in a build without needed
> to investigate then copy and paste the details.
>
> Maybe pkgconfig can provide more specific support for example we add a .pc for
> libbsd and then a user queries it for the needs flags to use?

Since the BSP provides the linker command file I think it is all right 
to provide the -Wl,--gc-sections unconditionally via the LDFLAGS of the 
pkg-config file. It doesn't affect code generation. It may confuse some 
application developers which don't know this linker feature if they see 
that some of their data gets magically optimized away and doesn't end up 
in the executable.

Providing the -fdata-sections and -ffunction-sections is not necessary. 
The application developers should think about this on their own if it 
makes sense for the application.

The pkg-config support is one of the last things to clarify in the new 
build system.