From: "Maciej W. Rozycki" <macro@wdc.com>
To: cltang@codesourcery.com
Cc: Julian Brown <julian@codesourcery.com>,
Mike Stump <mikestump@comcast.net>,
gcc-patches@gcc.gnu.org,
Thomas Schwinge <thomas@codesourcery.com>
Subject: Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot
Date: Tue, 11 Feb 2020 21:31:00 -0000 [thread overview]
Message-ID: <alpine.LFD.2.21.2002112108230.18621@redsun52.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <8a502b40-43d6-8e55-7fa6-1e4ed0f111f6@mentor.com>
Hi Chung-Lin,
> sorry for the late reply.
No worries.
> The 'AM_RUNTESTFLAGS = --tool_exec "$(CC)"' does work for us, but only because you backed out the change
> from libgomp-test-support.exp, and our installed testing doesn't use the libgomp/testsuite/Makefile.* files
> (we invoke runtest using another script).
>
> From the code in libgomp/testsuite/lib/libgomp.exp:libgomp_init():
> ...
> if ![info exists GCC_UNDER_TEST] then {
> if [info exists TOOL_EXECUTABLE] {
> set GCC_UNDER_TEST $TOOL_EXECUTABLE
> } else {
> set GCC_UNDER_TEST "[find_gcc]"
> }
> }
>
> So essentially this patch is the same as the prior one, and still blocks the usual find_gcc logic from
> ever getting control (as long as we use the in-tree 'make check'). I'm not sure that is the right
> thing to do...
That is intentional. The libgomp.exp test driver is generic and can be
invoked standalone (e.g. with `contrib/test_installed'), in which case the
user will decide with `runtest' options whether to use a compiler pointed
at explicitly or to fall back to `[find_gcc]'.
OTOH `make check' is tied to the build tree and I think it ought to use
the same compiler, there's no point in using any compiler search logic.
The only uncertainty was about libgomp-test-support.exp. Since it's
generated I concluded it could be treated as tied to the build tree,
however your use case has served as a counter example, so I have backed
out my change as I have come up with a change that is equally good for my
purpose and does not cause you and possibly other people trouble.
> That said, I don't have anything further against this patch. Okay for me.
Great, thanks for verifying my proposal.
> (I do still think that actually detecting the right in-tree compiler and giving the correct sysroot
> options from the configuration is the more proper approach, maybe later)
Well, the in-tree compiler is $(CC), $(CXX), etc., as embedded in the
Makefile structure, and I don't think you can guess it in DejaGNU without
referring to those `make' variables.
I'll post an updated series; it has passed my testing.
Maciej
next prev parent reply other threads:[~2020-02-11 21:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 18:12 [PATCH " Maciej W. Rozycki
2019-11-11 18:12 ` [PATCH 2/4] libffi/test: Fix " Maciej W. Rozycki
2019-11-11 18:12 ` [PATCH 1/4] libatomic/test: " Maciej W. Rozycki
2019-11-11 18:23 ` [golang-dev] [PATCH 0/4] Fix library testsuite " Ulderico Cirello
2019-11-11 18:29 ` Kaz Kylheku (libffi)
2019-11-11 18:42 ` Ian Lance Taylor
2019-11-11 18:35 ` Ian Lance Taylor
2019-11-11 18:45 ` Maciej W. Rozycki
2019-11-11 23:29 ` Ian Lance Taylor
2019-11-11 18:44 ` Maciej W. Rozycki
2019-11-26 15:56 ` [PING][PATCH " Maciej W. Rozycki
2019-12-02 14:49 ` [PING^2][PATCH " Maciej W. Rozycki
2019-12-09 21:30 ` [PING^3][PATCH " Maciej W. Rozycki
2019-12-17 0:06 ` [PING^4][PATCH " Maciej W. Rozycki
2019-12-21 1:30 ` Mike Stump
2019-12-22 1:34 ` Maciej W. Rozycki
2020-01-03 11:34 ` Julian Brown
2020-01-06 15:25 ` Maciej W. Rozycki
2020-01-09 21:00 ` Tobias Burnus
2020-01-14 13:43 ` Chung-Lin Tang
2020-01-21 3:21 ` Maciej W. Rozycki
2020-01-31 22:36 ` Maciej W. Rozycki
2020-02-11 8:35 ` Chung-Lin Tang
2020-02-11 21:31 ` Maciej W. Rozycki [this message]
2023-06-02 9:52 ` Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] Thomas Schwinge
2023-06-03 20:32 ` Maciej W. Rozycki
2023-09-12 9:35 ` libgomp: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951] (was: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]) Thomas Schwinge
2023-09-12 9:35 ` Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] " Thomas Schwinge
2020-01-06 15:47 ` [PING^5][PATCH 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
2020-01-13 21:20 ` [PING^6][PATCH " Maciej W. Rozycki
2020-01-21 2:44 ` [PING^7][PATCH " Maciej W. Rozycki
2020-01-26 21:07 ` Jeff Law
2020-02-13 23:37 ` Maciej W. Rozycki
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=alpine.LFD.2.21.2002112108230.18621@redsun52.ssa.fujisawa.hgst.com \
--to=macro@wdc.com \
--cc=cltang@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=julian@codesourcery.com \
--cc=mikestump@comcast.net \
--cc=thomas@codesourcery.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).