X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
	bh=8IyRpHfWI7HfmorPA4VS7ARO5yyzobnY2TD5yIra/hI=;
	b=BeIYUiRqrCLy1Ry5llrvJ5lzVsNT98pFYiwqJ2NP42P974l6PCQlgkjQgMC5VH0RA9
	Fa/Mg01cNPk7o5W1NhlyYGoFqJJgkh+7j6kaE6ySQ2U8r39U8tqhEWhaTJXVm1XvksWG
	CICEQsd+B2rR3v1kupeW9DW4g4n2XxVV5K78Vk7UoTJOX6pVGQbLHLGCZCUCwJeelhuv
	2ZP0BFUlGdzao3WFCuzM6xJckSXifqCgthGEIPjPgJVJbjWSX3jO5jwhMab3hwESjK2n
	6j7hIUtztPSlWUk/cx2a6z88+WOPBdfFzeJcXOQakPCtt5C7syB6Nt72os8ZX6Ec20nP
	+UUQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=8IyRpHfWI7HfmorPA4VS7ARO5yyzobnY2TD5yIra/hI=;
	b=C3s4Aawt8ABhqlbHTkjk/8qS2WvF143X1AqWPPkz1Ad/weENq8CQk7L+RMwV4a1r3M
	Fx0arWU7nMzM93cehWi5KJ65cqamhFtz9e6LDI0pUYThns2HobFbI+B02yjshJL5S83n
	4SaP7AC1lOAkEokj6EltHm1vIMVwKRgU/NdV7X8R1V8+UvwCntCiiSGQ2olhgmHWJRB/
	AJZ4JaX4EciflnaOBxevzzzQa3kSF0xmLGXfu6WIR8fWvca99W4upT8NNF+PISY0uL1a
	coPgeXuOLNHt/aayStpZ3/o5i8sQ8vOkDKckZ+b8zQfD8VVrTU9VXdCC9bunhMgZZHIe
	mlGg==
X-Gm-Message-State:	AOAM531Ah5NWZuVseknlKCcHF4m5cGx9Pl01DtBVoLDX9gz5ffvgBInz
	lEiNCXusQutAcwNyJmd0vNwUJlxz6Y7mybxXBGUxU8NKEjWA9Q==
X-Google-Smtp-Source:	ABdhPJwGHIEXuyu5/Q1pef31ylvbmnpZPXFCuldgjDOqlNGu+RkxB9x/fBmBJKGHPKyJi6W56C6fMiVsfvGhF6jL7F0=
X-Received:	by 2002:aa7:d5cf:: with SMTP id d15mr1970158eds.146.1606610506744;
	Sat, 28 Nov 2020 16:41:46 -0800 (PST)
MIME-Version:	1.0
References:	<CAN1+P_3UpFdU_V5bhaF+bT=9YG=qxjyVf7cgiM8etZL9EuKSGw AT mail DOT gmail DOT com>
	<CAN1+P_3Tj1yFHQ1ksFxWK-z1uuF+WtDoZ62rPy+wLp4bzUCU_A AT mail DOT gmail DOT com>
	<9d01fbcb-eae3-96c7-cc68-54c072dee20e AT iki DOT fi> <CAN1+P_0V5Y7Bn_K1AWpybNHqiEOpH1i5qc+Ca965nY9AAS+tvg AT mail DOT gmail DOT com>
	<CAN1+P_0MxAHta=HQ06dh5=CFpNS=STDQYtPfGSume6mokpLDuQ AT mail DOT gmail DOT com> <83zh31nbcx DOT fsf AT gnu DOT org>
In-Reply-To:	<83zh31nbcx.fsf@gnu.org>
From:	"Greg Kennedy (kennedy DOT greg AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Date:	Sat, 28 Nov 2020 18:41:35 -0600
Message-ID:	<CAN1+P_1tsGCRndvZfSMFOcPEvCHvcunpCiffNrNDryQwwbEFpw@mail.gmail.com>
Subject:	Re: GCC 10.2.0, collect2.exe error - cannot create temporary file
To:	djgpp AT delorie DOT com
Reply-To:	djgpp AT delorie DOT com

Tried again with that.  mkstemps calls open() from fcntl, which is
apparently returning EACCES.  So the problem is coming from djgpp's
libc somewhere.  I will keep digging...

While adding this it occurred to me that there are a *lot* of .o files
being linked at once here, plus a couple .a with stuff inside.  I
don't know what all happens in the intervening time between the
collect2 and the pex-common calls but it's possible there is a
resource limit being hit in the meantime (open file descriptors, stack
space, memory allocation, whatever).  -flto works on smaller projects,
but not this one.

Here's the printout.  (I also tried adding a ".pex" extension in
pex-common.c but it gave the same result - the problem isn't related
to the filenames in use)

collect2.c: make_temp_file(.ctc)
Called make_temp_file(.ctc), redirecting
Called make_temp_file_with_prefix(cc, .ctc): 'c:/djgpp/tmp/ccXXXXXX.ctc' ->
  mkstemps(c:/djgpp/tmp/ccXXXXXX.ctc, 4): trying
open(c:/djgpp/tmp/ccFoBQz9.ctc, ...)
  Got new file descriptor 5
-> 'c:/djgpp/tmp/ccFoBQz9.ctc'

collect2.c: make_temp_file(.cto)
Called make_temp_file(.cto), redirecting
Called make_temp_file_with_prefix(cc, .cto): 'c:/djgpp/tmp/ccXXXXXX.cto' ->
  mkstemps(c:/djgpp/tmp/ccXXXXXX.cto, 4): trying
open(c:/djgpp/tmp/ccaD2wZ8.cto, ...)
  Got new file descriptor 5
-> 'c:/djgpp/tmp/ccaD2wZ8.cto'

pex-common.c: make_temp_file(NULL)
Called make_temp_file((null)), redirecting
Called make_temp_file_with_prefix(cc, ): 'c:/djgpp/tmp/ccXXXXXX' ->
  mkstemps(c:/djgpp/tmp/ccXXXXXX, 0): trying open(c:/djgpp/tmp/ccF27J2I, ...)
  encountered fatal error during open: : Permission denied (EACCES)
  Zeroing pattern and returning -1
-> ''
Cannot create temporary file in c:/djgpp/tmp/: Permission denied (EACCES)
Abort!
Exiting due to signal SIGABRT

On Sat, Nov 28, 2020 at 2:24 AM Eli Zaretskii (eliz AT gnu DOT org) [via
djgpp AT delorie DOT com] <djgpp AT delorie DOT com> wrote:
>
> > From: "Greg Kennedy (kennedy DOT greg AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
> > Date: Fri, 27 Nov 2020 22:11:21 -0600
> >
> > I have added some debug print.  The problem is in pex-common.c, line
> > 109, which creates a temp file using make_temp_file(null);
> >
> > collect2.c: make_temp_file(.ctc)
> > Called make_temp_file(.ctc), redirecting
> > Called make_temp_file_with_prefix(cc, .ctc):
> > 'c:/djgpp/tmp/ccXXXXXX.ctc'-> 'c:/djgpp/tmp/ccehuQ7Q.ctc'
> > collect2.c: make_temp_file(.cto)
> > Called make_temp_file(.cto), redirecting
> > Called make_temp_file_with_prefix(cc, .cto):
> > 'c:/djgpp/tmp/ccXXXXXX.cto'-> 'c:/djgpp/tmp/ccioOw5x.cto'
> > pex-common.c: make_temp_file(NULL)
> > Called make_temp_file((null)), redirecting
> > Called make_temp_file_with_prefix(cc, ): 'c:/djgpp/tmp/ccXXXXXX'-> ''
> > Cannot create temporary file in c:/djgpp/tmp/: Permission denied (EACCES)
> > Abort!
>
> Given this trace, I think the problem is in libiberty's mkstemps,
> which is called with 'c:/djgpp/tmp/ccXXXXXX' and fails due to EACCES.
> Can you trace inside that as well?
>
> > I *think* the problem is that pex-common functions are being run "as a
> > subprocess", which may not have the same permissions as the original
> > launch process?
>
> No, that's not so.  It's collect2.exe that calls pex-common functions
> as part of its code.  And process permissions on MS-DOS have no
> meaning anyway.

- Raw text -