Hi Gerald, Development snapshots of gcc build with -Werror (this is turned off for releases), but we are not supposed to build with -Werror in ports. The fix: --- lang/gcc6-devel/Makefile +++ lang/gcc6-devel/Makefile @@ -96,6 +96,7 @@ CONFIGURE_ARGS+=--disable-nls \ --with-gxx-include-dir=${TARGLIB}/include/c++/ \ --with-ld=${LOCALBASE}/bin/ld \ ${ICONV_CONFIGURE_ARG} \ + --disable-werror \ --with-pkgversion="FreeBSD Ports Collection" \ --with-system-zlib MAKE_ARGS+= MAKEINFOFLAGS="--no-split" FYI, I hit this on dragonfly because gcc wrongly uses include <malloc.h> in at least 3 places: -o build/genchecksum.o .././../gcc-6-20150621/gcc/genchecksum.c /wrkdirs/lang/gcc6-devel/work/build/./prev-gcc/xg++ -B/wrkdirs/lang/gcc6-devel/work/build/./prev-gcc/ -B/usr/local/x86_64-portbld-dragonfly4.3/bin/ -nostdinc++ -B/wrkdirs/lang/gcc6-devel/work/build/prev-x86_64-portbld-dragonfly4.3/libstdc++-v3/src/.libs -B/wrkdirs/lang/gcc6-devel/work/build/prev-x86_64-portbld-dragonfly4.3/libstdc++-v3/libsupc++/.libs -isystem /wrkdirs/lang/gcc6-devel/work/build/prev-x86_64-portbld-dragonfly4.3/libstdc++-v3/include/x86_64-portbld-dragonfly4.3 -isystem /wrkdirs/lang/gcc6-devel/work/build/prev-x86_64-portbld-dragonfly4.3/libstdc++-v3/include -isystem /wrkdirs/lang/gcc6-devel/work/gcc-6-20150621/libstdc++-v3/libsupc++ -L/wrkdirs/lang/gcc6-devel/work/build/prev-x86_64-portbld-dragonfly4.3/libstdc++-v3/src/.libs -L/wrkdirs/lang/gcc6-devel/work/build/prev-x86_64-portbld-dragonfly4.3/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I.././../gcc-6-20150621/gcc -I.././../gcc-6-20150621/gcc/build -I.././../gcc-6-20150621/gcc/../include -I.././../gcc-6-20150621/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/inchash.o .././../gcc-6-20150621/gcc/inchash.c In file included from .././../gcc-6-20150621/gcc/system.h:481:0, from .././../gcc-6-20150621/gcc/genhooks.c:21: /usr/include/malloc.h:2:2: error: #warning "this file includes <malloc.h> which is deprecated, use <stdlib.h> instead" [-Werror=cpp] #warning "this file includes <malloc.h> which is deprecated, use <stdlib.h> instead" I can commit the fix if you approve.
ping. Gerald, is this okay to commit?
Hi John, GCC (when bootstrapping) intentionally builds stage 1 without any warning flags. What you ran into here looks like a genuine issue that GCC should not run into. I understand what you are saying, and were this any other GCC port, I would agree. This being GCC HEAD, this port really is a canary more than anything else, and definitely not intended for any production use. In my mind, I'd argue the port has fulfilled it's purpose by highlighting this issue and we should see that we can get this addressed properly. Any chance you can raise this upstream? (I'm curious, why did this occur only on DragonFly?)
Because FreeBSD check is slightly different. DragonFly <malloc.h>: #if __GNUC__ #warning "this file includes <malloc.h> which is deprecated, use <stdlib.h> instead" #endif #include <stdlib.h> FreeBSD <malloc.h>: /* $FreeBSD$ */ #if __STDC__ #error "<malloc.h> has been replaced by <stdlib.h>" #else #include <stdlib.h> #endif I've got about 2-3 things to bring up to gcc. GCC5 is now degraded on master branch wrt libstdc++ so there's 2 patches there (one to check PIE in testsuite) and another one for Ada. This would be the 4th and potentially the most difficult issue.
Could this be addressed via a Makefile.Dragonfly? If so, that's definitely pre-approved. These other 2-3 things, are they DragonFly-specific, or do they also affect FreeBSD? If the latter and/or in case of PIE, Andreas (copied now) might be able to help.
The -Werror issue is not critical. The patch on this PR is already in dports (which is an overlay of ports) so I can just leave it there. Issue 1 is Ada related and dragonfly-specific Issue 2 is c++ related and dragonfly-specific (plus I have good rapport with j.wakely) Issue 3 is just adding DragonFly as a valid platform for PIE tests. We've had PIE support from the beginning but the testsuite wasn't activated. So I don't think Andreas can help too much in these cases. As a side note, I'm thinking about sending test results to test-list on a regular basis (automated?). I need to talk to j.wakely about it... I might ask him about this malloc.h issue too and see what his advise is.
FYI: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00333.html https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00347.html
in system.h: #ifdef HAVE_MALLOC_H #include <malloc.h> #endif I guess DragonFly needs to do something to make sure HAVE_MALLOC_H is undefined. My guess is that it's defined because it exists - standard autoconf logic.
Let me take this PR over. I have a to-do to figure out how to make GCC understand that just because malloc.h exists on DragonFly (and FreeBSD) that it shouldn't be used. A fix for upstream.
We decided to remove /usr/include/malloc.h completely from DragonFly. There's a dragonfly "exp-run" going on with dports now. When it's finished and the no-malloc.h fallout is fixed, the malloc.h is going to get removed. Therefore no change to gcc will be required. Closing the PR.