> On May 10, 2019, at 08:07 , Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: > > On 10/05/2019 13:58, Gedare Bloom wrote: >> On Tue, May 7, 2019 at 5:03 AM Peter Dufault<dufa...@hda.com> 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 >>> >>> (...) >>> >>> LDFLAGS = $(LDFLAGS_GC_SECTIONS_DISABLE) >>> >>> 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 configure.ac/Makefile.am >> 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? Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
