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

Chris Johns chrisj at
Fri May 10 22:42:20 UTC 2019

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:
>>>> 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.



More information about the devel mailing list