From: Denys Dmytriyenko <denis@denix.org>
To: Darren Hart <dvhart@linux.intel.com>
Cc: Denys Dmytriyenko <denys@ti.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] rt-tests: fix dependency on eglibc, clean LDFLAGS passing
Date: Tue, 20 Mar 2012 14:59:37 -0400 [thread overview]
Message-ID: <20120320185937.GC22965@denix.org> (raw)
In-Reply-To: <4F68CEDA.2060101@linux.intel.com>
On Tue, Mar 20, 2012 at 11:39:22AM -0700, Darren Hart wrote:
> On 03/20/2012 09:09 AM, Denys Dmytriyenko wrote:
> > On Tue, Mar 20, 2012 at 08:33:14AM -0700, Darren Hart wrote:
> >>
> >>
> >> On 03/20/2012 08:28 AM, Denys Dmytriyenko wrote:
> >>> On Tue, Mar 20, 2012 at 08:01:44AM -0700, Darren Hart wrote:
> >>>>
> >>>>
> >>>> On 03/19/2012 05:22 PM, Denys Dmytriyenko wrote:
> >>>>> From: Denys Dmytriyenko <denys@ti.com>
> >>>>>
> >>>>> Replace dependency on eglibc with virtual/libc
> >>>>> Pass LDFLAGS to TARGET_CC_ARCH, instead of CFLAGS as Makefile overrides it
> >>>>>
> >>>>> Signed-off-by: Denys Dmytriyenko <denys@ti.com>
> >>>>
> >>>> Thanks Denys,
> >>>>
> >>>> Looking through the rt-tests sources I don't see TARGET_CC_ARCH
> >>>> anywhere. Have you confirmed that changes made there make their way into
> >>>> the actual build?
> >>>
> >>> Darren,
> >>>
> >>> TARGET_CC_ARCH is not an rt-tests specific variable, it's used in OE.
> >>> Although, TARGET_LDFLAGS might be more appropriate for this purpose,
> >>> historically TARGET_CC_ARCH was heavily used to pass distro LDFLAGS to the
> >>> app's build process - grepping it would show many such cases in OE-Core and
> >>> especially in meta-oe...
> >>
> >> OK, thanks for the context. Will you be resubmitting with TARGET_LDFLAGS?
> >
> > Nope, my bad, it's actually the other way around. From bitbake.conf:
> >
> > export LDFLAGS = "${TARGET_LDFLAGS}"
> >
> > So, appending to TARGET_CC_ARCH is the simplest way to pass flags, as that's
> > embedded into $CC
> >
> > Another option would have been to call make with -e flag to let environment
> > variables override the ones in the Makefile, but that's less controlled...
> >
>
> How about the follow patch against rt-tests? Clark W. said he's fine taking a
> patch that allows such an override. Does this meet your needs?
It does look good. Especially if it gets upstreamed! :)
If those default CFLAGS should always be there, then you can do something
like:
CFLAGS ?=
CFLAGS += -D_GNU_SOURCE -Wall -Wno-nonnull -Isrc/include
But that would mean there's no way to override those from outside, only add to
them...
Thanks for taking time to upstream the fix. I'll need to re-submit my patch to
only do the eglibc -> virtual/libc change.
--
Denys
> From 9f1944b0751ccb398a47fc4c3652c459aab44f38 Mon Sep 17 00:00:00 2001
> Message-Id: <9f1944b0751ccb398a47fc4c3652c459aab44f38.1332268655.git.darren@dvhart.com>
> From: Darren Hart <darren@dvhart.com>
> Date: Tue, 20 Mar 2012 11:34:08 -0700
> Subject: [PATCH] rt-tests: Support user supplied CFLAGS and LDFLAGS
>
> Accept user supplied CFLAGS and LDFLAGS, overwriting the
> Makefile supplied versions. This can cause the build to
> fail if the user does not provide at least what the Makefile
> defines, but so be it.
>
> Signed-off-by: Darren Hart <darren@dvhart.com>
> CC: Denys Dmytriyenko <denis@denix.org>
> ---
> Makefile | 25 +++++++++++++------------
> 1 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4038dcc..e1edf6c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -20,7 +20,8 @@ ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
> NUMA := 1
> endif
>
> -CFLAGS = -D_GNU_SOURCE -Wall -Wno-nonnull -Isrc/include
> +CFLAGS ?= -D_GNU_SOURCE -Wall -Wno-nonnull -Isrc/include
> +LDFLAGS ?=
>
> PYLIB := $(shell python -c 'import distutils.sysconfig; print distutils.sysconfig.get_python_lib()')
>
> @@ -61,41 +62,41 @@ all: $(TARGETS) hwlatdetect
> -include $(sources:.c=.d)
>
> cyclictest: cyclictest.o rt-utils.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS) $(NUMA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) $(NUMA_LIBS)
>
> signaltest: signaltest.o rt-utils.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
>
> pi_stress: pi_stress.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
>
> hwlatdetect: src/hwlatdetect/hwlatdetect.py
> chmod +x src/hwlatdetect/hwlatdetect.py
> ln -s src/hwlatdetect/hwlatdetect.py hwlatdetect
>
> rt-migrate-test: rt-migrate-test.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
>
> ptsematest: ptsematest.o rt-utils.o rt-get_cpu.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
>
> sigwaittest: sigwaittest.o rt-utils.o rt-get_cpu.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
>
> svsematest: svsematest.o rt-utils.o rt-get_cpu.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
>
> pmqtest: pmqtest.o rt-utils.o rt-get_cpu.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
>
> sendme: sendme.o rt-utils.o rt-get_cpu.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) $(EXTRA_LIBS)
>
> pip_stress: pip_stress.o error.o rt-utils.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
>
> hackbench: hackbench.o
> - $(CC) $(CFLAGS) -o $@ $^ $(LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
>
> CLEANUP = $(TARGETS) *.o .depend *.*~ *.orig *.rej rt-tests.spec *.d
> CLEANUP += $(if $(wildcard .git), ChangeLog)
> --
> 1.7.6.5
>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>
next prev parent reply other threads:[~2012-03-20 19:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 0:22 [PATCH] rt-tests: fix dependency on eglibc, clean LDFLAGS passing Denys Dmytriyenko
2012-03-20 15:01 ` Darren Hart
2012-03-20 15:11 ` Koen Kooi
2012-04-07 3:34 ` Khem Raj
2012-03-20 15:28 ` Denys Dmytriyenko
2012-03-20 15:33 ` Darren Hart
2012-03-20 16:09 ` Denys Dmytriyenko
2012-03-20 16:22 ` Darren Hart
2012-03-20 18:39 ` Darren Hart
2012-03-20 18:59 ` Denys Dmytriyenko [this message]
2012-03-20 19:03 ` Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120320185937.GC22965@denix.org \
--to=denis@denix.org \
--cc=denys@ti.com \
--cc=dvhart@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.