> On May 10, 2019, at 18:42 , Chris Johns <chr...@rtems.org> wrote: > > On 10/5/19 10:27 pm, dufa...@hda.com wrote: >> >> >>> On May 10, 2019, at 08:07 , Sebastian Huber >>> <sebastian.hu...@embedded-brains.de >>> <mailto: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 >>>> <mailto: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? > > 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 Makefile.am's. > > The Makefile.inc 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 https://devel.rtems.org/ticket/3302. > > 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] https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n79 > [2] https://git.rtems.org/rtems_waf/tree/rtems.py#n793 > <https://git.rtems.org/rtems_waf/tree/rtems.py#n793>
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 ----------------- 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
