X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Date: Sat, 28 Nov 2020 10:18:06 +0200
Message-Id: <83zh31nbcx.fsf@gnu.org>
From: "Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To: djgpp AT delorie DOT com
In-Reply-To:
	<CAN1+P_0MxAHta=HQ06dh5=CFpNS=STDQYtPfGSume6mokpLDuQ AT mail DOT gmail DOT com>
	(djgpp AT delorie DOT com)
Subject: Re: GCC 10.2.0, collect2.exe error - cannot create temporary file
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>
Reply-To: djgpp AT delorie DOT com

> 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.