Hello,
I noticed that some objects are compiled without cflags.
See attached patch that fixes the situation. :)
Cheers
Tom
Tomas Chvatal TChvatal@suse.com writes:
I noticed that some objects are compiled without cflags.
Was there any concrete problem?
See attached patch that fixes the situation. :)
I'm afraid it can break cross compilation. CFLAGS are for flags appropriate for the cross compiler. While the various programs built using $(CC_FOR_BUILD) are always native binaries. To be concrete, consider cross compiling for arm on a x86 build machine, and $(CFLAGS) choosen to select whether or not to enable generation of arm neon instructions. Passing those flags also to the native compiler won't work.
Regards, /Niels
Niels Möller píše v Út 02. 08. 2016 v 17:09 +0200:
Tomas Chvatal TChvatal@suse.com writes:
I noticed that some objects are compiled without cflags.
Was there any concrete problem?
See attached patch that fixes the situation. :)
I'm afraid it can break cross compilation. CFLAGS are for flags appropriate for the cross compiler. While the various programs built using $(CC_FOR_BUILD) are always native binaries. To be concrete, consider cross compiling for arm on a x86 build machine, and $(CFLAGS) choosen to select whether or not to enable generation of arm neon instructions. Passing those flags also to the native compiler won't work.
Regards, /Niels
Hello, we have checks that verify all objects are compiled with respecting cflags set in the distribution (hardening, optimization, etc.).
If there is object not doing that I get errors on it. Thus it should be able to do so.
Hmm with the cross-compilation I am not sure how that should be handled properly but simply ignoring all other cflags on those objects does not seem like right solution.
Tom
Tomas Chvatal TChvatal@suse.com writes:
we have checks that verify all objects are compiled with respecting cflags set in the distribution (hardening, optimization, etc.).
I see. And you can't easily exclude executables which are never installed? Note that the Makefile rules where CC_FOR_BUILD is used produce executables directly from a .c file, with no explicit object files.
Hmm with the cross-compilation I am not sure how that should be handled properly but simply ignoring all other cflags on those objects does not seem like right solution.
I see two reasonable solutions. If possible, try both and report what works. Either explicitly pass CC_FOR_BUILD="gcc --whatever-flags-you-want" on the configure command line produced by your build scripts. Or change the no-cross default, like
--- a/aclocal.m4 +++ b/aclocal.m4 @@ -514,7 +514,7 @@ elif test -n "$HOST_CC"; then [AC_MSG_ERROR([Specified HOST_CC doesn't seem to work])]) else if test $cross_compiling = no ; then - CC_FOR_BUILD="$CC" + CC_FOR_BUILD="$(CC) $(CFLAGS)" else for i in gcc cc c89 c99; do GMP_PROG_CC_FOR_BUILD_WORKS($i,
(untested, not sure if this makefile syntax in CC_FOR_BUILD breaks any use outside of Makefile).
And I guess you'll have the same problem when building gmp, so I'm cc:ing the gmp-devel list as well.
Regards, /Niels
On Wed, Aug 3, 2016 at 11:10 AM, Tomas Chvatal TChvatal@suse.com wrote:
Hello, we have checks that verify all objects are compiled with respecting cflags set in the distribution (hardening, optimization, etc.).
That shouldn't matter because the code you mentioned is not installed in the target system. It is code that generates tables used in nettle.
regards, Nikos
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se -
Tomas Chvatal