Permission denied on a.out in ./configure

Clayton Daley clayton.daley at
Thu Sep 18 21:44:52 UTC 2014

I totally understand and don't expect you to move mountains for an edge
case, but I don't mind reporting "maybe you care" issues either.

Incidentally, a fix at my end was to replace "./a.out" with "sh ./a.out" in
configure.  The rest of the process ran fine (except, the final make
install since I don't have permission).  The "better" approach -- of course
-- would have been to extend the lines that check "./a.out" with additional
"or"s for the same files using "sh" (but I didn't need to preserve the
original checks).

Up to you whether this kind of edge case is worth gumming up the configure

Clayton Daley

On Thu, Sep 18, 2014 at 3:55 PM, Torbjörn Granlund <tg at> wrote:

> Clayton Daley <clayton.daley at> writes:
>   FYI... I checked umask and that did't fix it.
>   I would also argue that gmp is responsible (at least partly) since
>   configure *does* actually find a working compiler, but believes otherwise
>   (because it doesn't have execute permissions). It still may be right to
>   raise an error instead of continuing the install (e.g. if configure or
> make
>   actually needs execute privileges to files), but that's something I had
> to
>   ask here to confirm.
> GMP cannot run its checks for whether the compiler works without being
> able to execute elementary tests.
> It is not realistic to expect the configure process to try to diagnose
> the reasons why executables don't work.  It can be hundreds of reasons,
> including various file systems modes and file protection mechanisms
> (file mode bits, ACLs, file flags, mount mode, etc) and space issues
> (full disk, inode shortage, exceeded quota, etc).
> --
> Torbjörn
> Please encrypt, key id 0xC8601622

More information about the gmp-discuss mailing list