public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Julian Brown <julian@codesourcery.com>
To: "Maciej W. Rozycki" <macro@wdc.com>
Cc: 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: Fri, 03 Jan 2020 11:34:00 -0000	[thread overview]
Message-ID: <20200103113421.51b55ff5@squid.athome> (raw)
In-Reply-To: <alpine.LFD.2.21.1912220031100.30965@redsun52.ssa.fujisawa.hgst.com>

Hi Maciej,

On Sun, 22 Dec 2019 00:43:54 +0000 (GMT)
"Maciej W. Rozycki" <macro@wdc.com> wrote:

> On Fri, 20 Dec 2019, Mike Stump wrote:
> 
> > >> This patch series addresses a problem with the testsuite
> > >> compiler being set up across libatomic, libffi, libgo, libgomp
> > >> with no correlation whatsoever to the target compiler being used
> > >> in GCC compilation. Consequently there in no arrangement made to
> > >> set up the compilation sysroot according to the build sysroot
> > >> specified for GCC compilation, causing a catastrophic failure
> > >> across the testsuites affected from the inability to link
> > >> executables.  
> > > 
> > > Ping for:
> > > 
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>  
> > 
> > Hum...  I'm wondering who should review this...  Feels like I
> > should, the problem is it intertwines with the build system as
> > well.  So, let me approve the testsuite parts so that can clear the
> > way for someone else to approve the remaining bits (if not
> > obvious).  
> 
>  Thanks for your review; I have applied 4/4 as it doesn't contain any 
> non-testsuite parts and will continue pinging 1/4 and 2/4 for the
> build system bits then (3/4 has been already committed by the Go
> maintainer).
> 
> > Please do watch out for breakages as it goes in.  Thanks.  
> 
>  Sure!

FYI: This patch seems to be causing problems for our (internal -- as
you know!) test harness. I'm not sure if it's a local issue (or at least
something we can work around here), or a problem with the patch itself
though.

I'm currently working on offloading-enabled compilers. I see the same
failure mode for both AMD GCN and NVPTX.

Without the patch, the compiler is found (with [find_gcc] I suppose) and
invoked as x86_64-none-linux-gnu-gcc. That works fine for us, but we do
(I think) "installed testing", which IIUC is atypical.

With the patch, the compiler is invoked as (at the risk of excessive
detail) e.g.:

/scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/xgcc -B/scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/lib/ -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/include -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/sys-include --sysroot=/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/libc [...]

...and then it fails to find libgomp.spec:

xgcc: fatal error: cannot read spec file 'libgomp.spec': No such file or directory

Can your approach be made to work with an offload-enabled compiler? How
should that spec file (and/or the target compiler) be located?

Thanks,

Julian

  reply	other threads:[~2020-01-03 11:34 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 [this message]
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
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=20200103113421.51b55ff5@squid.athome \
    --to=julian@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=macro@wdc.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).