Issue in detection of assembler support for --noexecstack flag
rahulchaudhry at chromium.org
Thu Feb 25 18:22:21 UTC 2016
This was discovered while trying to use llvm/clang to configure and
build gmp. This is the bug for this issue on the llvm side:
It is true that irrespective of the flags being passed, the error
messages from the llvm assembler are weird and unexpected.
The acinclude.m4 change in the attached patch is still is a good
change, though, independent of the llvm bug. Note that the same macro
adds the "--noexecstack" flag to ASMFLAGS after checking if it is
supported. The flag gets used later during the build, so I'm assuming
that ASMFLAGS is used from the Makefiles when invoking the assembler.
It makes little sense to use CFLAGS when invoking the assembler to
check support for the "--noexecstack" flag. The only explanation I can
think of is that this is how glibc did it, and this macro was borrowed
from there. And if that's the only reason, then glibc fixed this exact
instance and the patch is bringing that fix to gmp.
On Thu, Feb 25, 2016 at 8:27 AM, Marc Glisse <marc.glisse at inria.fr> wrote:
> On Wed, 24 Feb 2016, Rahul Chaudhry wrote:
>> I'm reporting a configure issue and attaching a patch to fix it.
>> Apologies if this is not the right forum for it (and please point to
>> the proper channel if that's the case).
>> We're hitting an issue where configure incorrectly determines that the
>> assembler does not support the "--noexecstack" flag.
>> The problem is with how the script tries to detect support for this
>> flag. During configure, the assembler command fails with:
>> conftest.s:8:8: error: file number already allocated
> Independently of what we do in GMP, it would be nice if someone could file a bug with binutils as asked in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35925 .
>> According to acinclude.m4, the macro for this was adapted from one
>> found in glibc-2.3.5.
>> A similar issue was reported for glibc:
>> This was fixed in glibc on 15 May 2008:
>> The fix is to use $ASMFLAGS (instead of $CFLAGS) when invoking the assembler.
>> The attached patch applies the fix to the macro in acinclude.m4
> I don't feel very confident about doing that. We do a lot of things with CFLAGS in configure but don't touch ASMFLAGS at all, so it might not be very consistent with CFLAGS.
> One workaround you could try is:
> CC='gcc -g1'
> CCAS='gcc -c'
> Marc Glisse
More information about the gmp-bugs