Conditionalize make behavior e.g. disable --gc-sections

dufault at dufault at
Sun May 12 09:43:30 UTC 2019

> On May 10, 2019, at 18:42 , Chris Johns <chrisj at> wrote:
> On 10/5/19 10:27 pm, dufault at wrote:
>>> On May 10, 2019, at 08:07 , Sebastian Huber
>>> <sebastian.huber at
>>> <mailto:sebastian.huber at>> wrote:
>>> On 10/05/2019 13:58, Gedare Bloom wrote:
>>>> On Tue, May 7, 2019 at 5:03 AM Peter Dufault<dufault at
>>>> <mailto:dufault at>>  wrote:
>>>>> What is best practice to change build behavior?  e.g. I need to use
>>>>> --whole-archive/--no-whole-archive in one place but --gc-sections breaks it
>>>>> and that's turned on for the BSP (xilinx_zynq_a9_qemu).
>>>>> I’ve done this in the .cfg files for the BSP:
>>>>> ifneq ($(RTEMS_GC_SECTIONS_DISABLE),1)
>>>>> LDFLAGS_GC_SECTIONS_DISABLE = -Wl,--gc-sections
>>>>> endif
>>>>> (...)
>>>>> and then I set RTEMS_GC_SECTIONS_DISABLE=1 in the one Makefile where I need
>>>>> it.  I don’t see similar patterns, is this the way to do it?
>>>> Historically a new BSP variant has been introduced when there needs to
>>>> be a change at this .cfg level. But, I could see a rationale to
>>>> include this kind of switching behavior at a higher level. Someone
>>>> might consider how to integrate it into our
>>>> black magic, but that is beyond me:).
>>>> An alternative approach that may work from what you propose is to use
>>>> following in the xilinx zynq .cfg file:
>>>> LDFLAGS ?= -Wl, --gc-sections
>>>> then, you can provide own LDFLAGS = -Wl on your make command line or
>>>> in your Makefile, I think that would work bit more elegant
>>> Nobody forces you to use -Wl, --gc-sections to link your application. For the
>>> RTEMS tests and samples this shouldn't be an issue?
>> My make pulls in those settings.  I think it is best to use the same settings
>> that the RTEMS tests and samples unless I have a good reason to change them,
>> e.g., I need —whole-archive in one application in one place.
>> What do you recommend?  Where is an example to build from?
> We do not have simple examples with documentation to support them. I receive a
> stream of requests about building libdl applications and all I can do is point
> user to the testsuite's.
> The approach has a range of problems so adding documentation and
> examples based on it is something I do not support. The approach I would like to
> see happen is documented in
> You do not need to build applications with the exact same flags that the kernel
> uses however you need to be careful in managing what you do use. As I state in
> the ticket RTEMS Tools [1] and RTEMS Waf [2] both have support to filter the
> CFLAGS into parts so you can manage what is used when building applications. I
> would prefer this is formalised when exported by RTEMS rather than having to
> have this fragile code which does break from time to time.
> Chris
> [1]
> [2] <>

I’ll make a summary and then move on to other items.  Thanks all, I’ve gotten what I need from the discussion.

Gedare: I don’t like “?=“ in any complicated setting because you need to hunt around to make sure nothing has already over-ridden default behavior.  A “request” such as setting RTEMS_GC_SECTIONS_DISABLE=1 is globally clear as to what it is trying to be accomplish at a local level and harder to responsibly break.

Sebastian: I still don’t understand what your comment suggests, I almost never feel forced to do anything.  When using a BSP I want to build with the settings used by the developer and that the tests are run on.  I don’t want to modify them much unless I need to.  In this case the standard settings break another flag. You don’t need to answer - this is not that important.

Chris: Your response is appropriate for the -devel list and beyond where I want to go on this subject right now.  I’ll add the requirement that someone coming from a Makefile based build system must find it easy to get started with RTEMS and incorporate the libraries into their project without digging deeply into details.

Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list