From: pvorel@suse.cz (Petr Vorel)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH v2] autodetect fts support and tests depending on it
Date: Thu, 21 Mar 2019 13:06:45 +0100 [thread overview]
Message-ID: <20190321120645.GB17345@dell5510> (raw)
In-Reply-To: <3601d849-46fa-b9cd-0a6d-882c8ed9c73f@synopsys.com>
Hi Vineet,
> On 3/20/19 3:37 PM, Petr Vorel wrote:
> >> +# controllers/cpuset/cpuset_lib/libcpuset.c uses fts
> >> +# which may not be available/configured in the libc build
> >> +ifndef HAVE_FTS_H
> >> +FILTER_OUT_DIRS += cpuset
> >> +endif
> > Have you tested it?
> Absolutely. I verified again. With this patch reverted locally I see errors due to
> it trying to build the file
I meant testing with glibc :). Because your patch would bring a regression:
ifndef HAVE_FTS_H is always true because HAVE_FTS_H as an autotools check is not
visible to make in this form, no matter what it's set to HAVE_FTS_H in
include/config.h :(.
We could solve previous problem to make HAVE_FTS_H visible with AC_SUBST, while
creating proper autotools function check in m4/. Planning to do that? (if not
I'll do).
My thoughts about dependency problem in shell scripts (TST_TEST_TCONF) was wrong
as these tests are also under cpuset directory.
> With my patch the build runs to completion.
> This will not work as HAVE_LIBAIO_H is in include/config.h,
> You mean HAVE_FTS_H (LIBAIO stuff is for different patch)
> > thus only for C. For Makefile it must be done via autotools (search for AC_SUBST
> > in m4/). I thought TST_TEST_TCONF usage, but you're right, that problematic
> > source is part of libcontrollers.a (i.e. part of a library, not normal C
> > binary).
> Umm not sure what u mean. Going to read the next msg in thread.
See up.
Kind regards,
Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2] autodetect fts support and tests depending on it
Date: Thu, 21 Mar 2019 13:06:45 +0100 [thread overview]
Message-ID: <20190321120645.GB17345@dell5510> (raw)
In-Reply-To: <3601d849-46fa-b9cd-0a6d-882c8ed9c73f@synopsys.com>
Hi Vineet,
> On 3/20/19 3:37 PM, Petr Vorel wrote:
> >> +# controllers/cpuset/cpuset_lib/libcpuset.c uses fts
> >> +# which may not be available/configured in the libc build
> >> +ifndef HAVE_FTS_H
> >> +FILTER_OUT_DIRS += cpuset
> >> +endif
> > Have you tested it?
> Absolutely. I verified again. With this patch reverted locally I see errors due to
> it trying to build the file
I meant testing with glibc :). Because your patch would bring a regression:
ifndef HAVE_FTS_H is always true because HAVE_FTS_H as an autotools check is not
visible to make in this form, no matter what it's set to HAVE_FTS_H in
include/config.h :(.
We could solve previous problem to make HAVE_FTS_H visible with AC_SUBST, while
creating proper autotools function check in m4/. Planning to do that? (if not
I'll do).
My thoughts about dependency problem in shell scripts (TST_TEST_TCONF) was wrong
as these tests are also under cpuset directory.
> With my patch the build runs to completion.
> This will not work as HAVE_LIBAIO_H is in include/config.h,
> You mean HAVE_FTS_H (LIBAIO stuff is for different patch)
> > thus only for C. For Makefile it must be done via autotools (search for AC_SUBST
> > in m4/). I thought TST_TEST_TCONF usage, but you're right, that problematic
> > source is part of libcontrollers.a (i.e. part of a library, not normal C
> > binary).
> Umm not sure what u mean. Going to read the next msg in thread.
See up.
Kind regards,
Petr
next prev parent reply other threads:[~2019-03-21 12:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 17:44 [PATCH] cpuset: disable for UCLIBC Vineet Gupta
2019-03-12 17:44 ` [LTP] " Vineet Gupta
2019-03-14 10:01 ` Petr Vorel
2019-03-14 10:01 ` Petr Vorel
2019-03-18 16:41 ` Vineet Gupta
2019-03-18 16:41 ` Vineet Gupta
2019-03-18 18:19 ` Petr Vorel
2019-03-18 18:19 ` Petr Vorel
2019-03-18 19:52 ` [PATCH v2] autodetect fts support and tests depending on it Vineet Gupta
2019-03-18 19:52 ` [LTP] " Vineet Gupta
2019-03-20 22:37 ` Petr Vorel
2019-03-20 22:37 ` [LTP] " Petr Vorel
2019-03-20 22:47 ` Petr Vorel
2019-03-20 22:47 ` Petr Vorel
2019-03-20 23:11 ` Vineet Gupta
2019-03-20 23:11 ` [LTP] " Vineet Gupta
2019-03-21 12:06 ` Petr Vorel [this message]
2019-03-21 12:06 ` Petr Vorel
2019-03-21 15:48 ` Vineet Gupta
2019-03-21 15:48 ` [LTP] " Vineet Gupta
2019-03-18 20:06 ` [PATCH] auto filter aio tests of libc can't support aio Vineet Gupta
2019-03-18 20:06 ` [LTP] " Vineet Gupta
2019-03-20 22:48 ` Petr Vorel
2019-03-20 22:48 ` [LTP] " Petr Vorel
2019-03-21 21:43 ` Vineet Gupta
2019-03-21 21:43 ` [LTP] " Vineet Gupta
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=20190321120645.GB17345@dell5510 \
--to=pvorel@suse.cz \
--cc=linux-snps-arc@lists.infradead.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.