| Summary: | ASTERISK-25289: Build System does not respect CFLAGS and CXXFLAGS when building menuselect | ||||||||
| Reporter: | Jeffrey Walton (noloader@gmail.com) | Labels: | |||||||
| Date Opened: | 2015-07-28 20:56:30 | Date Closed: | 2016-07-13 06:14:01 | ||||||
| Priority: | Major | Regression? | |||||||
| Status: | Closed/Complete | Components: | Core/BuildSystem | ||||||
| Versions: | 11.22.0 13.9.1 | Frequency of Occurrence | Constant | ||||||
| Related Issues: |
| ||||||||
| Environment: | Fedora 22, x86_64; but any distro with a compiler with sanitizers will do (excpet maybe Clang, since it reject's the use of trampolines that Asterisk uses). | Attachments: | ( 0) cflag_alternative_A.patch ( 1) cflag_alternative_B.patch ( 2) config.log | ||||||
| Description: | GCC added sanitizers at 4.8. I'm attempting to build Asterisk with the UBsan (undefined behavior) and Asan (address) sanitizers enabled. UBsan is enabled with `-fsanitize=undefined`, and Asan is enabled with `-fsanitize=address`. (UBasan and Asan are mutually exclusive, so we repeat the steps below twice).
localhost asterisk-13.4.0]$ export CFLAGS=-fsanitize=undefined localhost asterisk-13.4.0]$ export CXXFLAGS=-fsanitize=undefined localhost asterisk-13.4.0]$ ./configure ... Looking at the config.log, it appears the CFLAGS and CXXFLAGS were tested and accepted. Then: configure: Package configured for: configure: OS type : linux-gnu configure: Host CPU : x86_64 configure: build-cpu:vendor:os: x86_64 : unknown : linux-gnu : configure: host-cpu:vendor:os: x86_64 : unknown : linux-gnu : localhost asterisk-13.4.0]$ make CC="cc" CXX="g++" LD="" AR="" RANLIB="" CFLAGS="" LDFLAGS="" make -C menuselect CONFIGURE_SILENT="--silent" makeopts make[1]: Entering directory '/home/jwalton/Desktop/asterisk-13.4.0/menuselect' make[1]: 'makeopts' is up to date. make[1]: Leaving directory '/home/jwalton/Desktop/asterisk-13.4.0/menuselect' CC="cc" CXX="g++" LD="" AR="" RANLIB="" CFLAGS="" LDFLAGS="" make -C menuselect CONFIGURE_SILENT="--silent" menuselect make[1]: Entering directory '/home/jwalton/Desktop/asterisk-13.4.0/menuselect' gcc -g -D_GNU_SOURCE -Wall -I/usr/include/libxml2 -c -o menuselect.o menuselect.c gcc -g -D_GNU_SOURCE -Wall -c -o strcompat.o strcompat.c gcc -g -D_GNU_SOURCE -Wall -c -o menuselect_stub.o menuselect_stub.c gcc -o menuselect menuselect.o strcompat.o menuselect_stub.o -lxml2 -lz -lm -ldl make[1]: Leaving directory '/home/jwalton/Desktop/asterisk-13.4.0/menuselect' Generating input for menuselect ... menuselect/menuselect --check-deps menuselect.makeopts Unknown value '' found in build_tools/menuselect-deps for NATIVE_ARCH *********************************************************** The existing menuselect.makeopts file did not specify that 'BUILD_NATIVE' should not be included. However, either some dependencies for this module were not found or a conflict exists. Either run 'make menuselect' or remove the existing menuselect.makeopts file to resolve this issue. *********************************************************** Makefile:344: recipe for target 'menuselect.makeopts' failed make: *** [menuselect.makeopts] Error 255 | ||||||||
| Comments: | By: Jeffrey Walton (noloader@gmail.com) 2015-07-28 20:58:09.645-0500 Transcript for configure By: Jeffrey Walton (noloader@gmail.com) 2015-07-29 05:36:13.428-0500 I'm probably not parsing something correctly... ASTERISK 25289 was closed as a duplicate of ASTERISK 25290 (this report). Then this report was closed as a duplicate of itself. ASTERISK 25289 issue was CFLAGS and CXXFLAGS were not respected when exported from the environment. I.e, export CFLAGS="..."; exportCXXFLAGS="$CFALGS" ./configure make ASTERISK 25290 issue was CFLAGS and CXXFLAGS were not respected on the command line. I.e, make CFLAGS="..." CXXFLAGS="..." By: Joshua C. Colp (jcolp) 2015-07-29 05:40:27.618-0500 This issue is ASTERISK-25289, not ASTERISK-25290, and the underlying issue is the same between both issues which I've updated the title of this issue to reflect. By: Alexander Traud (traud) 2016-07-12 04:18:18.194-0500 The configure script did not set AST_NATIVE_ARCH to the value 0 but tried to use an undefined value instead. That is not understood by menuselect and created this error. Furthermore, the configure script disabled BUILD_NATIVE in menuselect completely, when CFLAG were supplied to the configure script. This was intended to allow custom -march= values, although one can do this via the menuselect interface(s). The attached patch B fixes both of these issue. The attached patch A fixes just the issue reported here. By: abelbeck (abelbeck) 2016-09-05 08:50:30.052-0500 The resulting fix for this issue does not take into account for "cross-compiling". http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=commit;h=3be6fa1e4b920fe1ccec67e4a78e101354a767d9 Our project has cross-compiled Asterisk for many years, we pass CFLAGS and the resulting AST_NATIVE_ARCH was undefined, it worked. Then with Asterisk 13.11.0 the resulting binary crashed with illegal operand at startup, shortly after reading "/etc/localtime". After much head-scratching and hair-pulling I discovered this change and -march=native was being defined behind our back. Adding: {noformat}menuselect/menuselect --disable BUILD_NATIVE menuselect.makeopts{noformat} solves the problem, but it would seem less fragile and better to add the condition {noformat}if test "${cross_compiling}" = "no";{noformat} to whether AST_NATIVE_ARCH=1 is set. By: Alexander Traud (traud) 2016-09-06 02:41:00.121-0500 [~abelbeck], which CFLAGS are you using exactly?{noformat}make menuselect.makeopts menuselect/menuselect --disable BUILD_NATIVE{noformat}When cross-compiling, didn’t you make Menuselect? I am curious, because an undefined value for AST_NATIVE_ARCH should have broken your Menuselect. I wonder whether AST_NATIVE_ARCH=0 works in your case as well. The Asterisk team has problems to follow-up on comments to already closed reports. Why ever. One solution is to go for the ‘Retriage Issue’ button at the top when you logged into Jira. However, I am not sure whether all members get that button. Therefore, another approach is to report a new issue. Then, via the ‘More’ button, you link this report here as ‘caused by'. I am not able to do this on behalf of you or the team, therefore I can only suggest that. This is no devaluation of your report, quite the contrary, this suggestion is about speeding up the inclusion of your suggestion. Furthermore, if feasible, please attach a patch created via {{diff -u}}, after you created the new report, again via the button ‘More’. That eases to understand where in code (when exactly) you want to test for the shell environment variable [cross_compiling|https://www.gnu.org/software/autoconf/manual/html_node/Runtime.html]. For example, I guess you meant ‘… whether to set AST_NATIVE_ARCH=1’, so that test should come before {noformat}if $(${CC} -march=native …{noformat} By: abelbeck (abelbeck) 2016-09-06 09:31:02.950-0500 Alexander, we use Buildroot to cross-compile, so a lot of CFLAGS are set. Yes we use menuselect/menuselect, here is an example from Asterisk 11.23.0 without this fix. {noformat} (cd /home/dev/astlinux/1.0/output/build/asterisk-11.23.0; \ menuselect/menuselect --enable res_pktccops menuselect.makeopts; \ menuselect/menuselect --disable CORE-SOUNDS-EN-GSM --disable MOH-OPSOUND-WAV menuselect.makeopts; \ menuselect/menuselect --disable BUILD_NATIVE menuselect.makeopts; \ ) Unknown value '' found in build_tools/menuselect-deps for NATIVE_ARCH Unknown value '' found in build_tools/menuselect-deps for HAVE_LEAK_SANITIZER Unknown value '' found in build_tools/menuselect-deps for HAVE_UNDEFINED_SANITIZER Unknown value '' found in build_tools/menuselect-deps for NATIVE_ARCH Unknown value '' found in build_tools/menuselect-deps for HAVE_LEAK_SANITIZER Unknown value '' found in build_tools/menuselect-deps for HAVE_UNDEFINED_SANITIZER Unknown value '' found in build_tools/menuselect-deps for NATIVE_ARCH Unknown value '' found in build_tools/menuselect-deps for HAVE_LEAK_SANITIZER Unknown value '' found in build_tools/menuselect-deps for HAVE_UNDEFINED_SANITIZER {noformat} While all the error messages are annoying, each menuselect/menuselect returns with "0" and works as expected. For cross-compiling AST_NATIVE_ARCH=0 would seem like the proper choice to be generated. The NATIVE_ARCH feature was reviewed here: https://reviewboard.asterisk.org/r/1852/ I'm somewhat puzzled why AST_NATIVE_ARCH= (undefined) was introduced, it would seem only AST_NATIVE_ARCH=0 and AST_NATIVE_ARCH=1 would be needed. By: Alexander Traud (traud) 2016-09-06 12:17:32.290-0500 Interesting, because in Jeffreys (original reporter here), my case, the mentioned report in the mailing list, and several reports on the discussion board, Menuselect was not made at all when CFLAGS was given to ./configure. In your case, was Menuselect made before you gave a CFLAGS to ./configure (aka do you make distclean in between)? Furthermore although not related to this issue, I wonder why you do several {{menuselect/menuselect}} and one {{menuselect.makeopts}} after each enable/disable. I have no idea either what happened in that code review. As you noted, AST_NATIVE_ARCH=0 should have been used instead of Undefined. Furthermore, CFLAGS should not disable AST_NATIVE_ARCH because that is not related. Adding your {{cross_compiling}} check to change the default value of {{BUILD_NATIVE}} sounds reasonable to me. Please create a new issue report for that. By: abelbeck (abelbeck) 2016-09-06 16:16:40.511-0500 ASTERISK-26342 is created to continue this discussion. Alexander, in my testing AST_NATIVE_ARCH= (undefined) and AST_NATIVE_ARCH=0 appear to work the same wrt the menuselect command, except AST_NATIVE_ARCH=0 does not generate errors as AST_NATIVE_ARCH= does. We make and call menuselect after ./configure is run, we have to patch configure.ac to keep menuselect from being called by ./configure and our asterisk.mk makes it work. All needed because we cross-compile. We call menuselect multiple times mostly because we support Asterisk 1.8, 11 and 13 all in one asterisk.mk and we enable or disable features per the Asterisk version and which external packages being enabled. | ||||||||