Bug 207125
| Summary: | lang/gcc9: (clang used to build) CFLAGS for clang stops portmaster lang/gcc9 build | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Mark Millard <marklmi26-fbsd> |
| Component: | Individual Port(s) | Assignee: | freebsd-toolchain (Nobody) <toolchain> |
| Status: | Closed Not Enough Information | ||
| Severity: | Affects Some People | CC: | gerald, lwhsu, miwi, tatsuki_makino |
| Priority: | --- | Keywords: | needs-qa |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
(In reply to Mark Millard from comment #0) Using 11.0 -r301815 to attempt to build the the newly created lang/gcc6 on an rpi2 [armv7-a/cortex-a7] with CCFLAGS containing -march=armv7a during the build lead to various rejections by xgcc or other such gcc stages: they require -march=armv7-a instead if -march is to be used for armv7-a. This means failing config tests because the compile commands are rejected. So this is another example of the type of thing that I originally reported. If the system clang is to build a lang/gcc* (or devel/*gcc* ?) then the CCFLAGS and the like have to be set to be compatible for both clang and gcc. (I've not checked if ports get CCFLAGS.gcc and CCFLAGS.clang and the like that could keep the flags for building gcc separate from the flags for running gcc as long as clang is building gcc.) I won't be able to address this via the lang/gcc* ports anytime soon (and it is more an infrastructure issue where indeed different flavors of CFLAGS seem a good approach). Hey, Is this problem still relevant? (In reply to Martin Wilke from comment #3) Summary of the below: yes. If, as a means of testing, I specify: # svnlite diff /usr/ports/lang/gcc6/Makefile Index: /usr/ports/lang/gcc6/Makefile =================================================================== --- /usr/ports/lang/gcc6/Makefile (revision 468668) +++ /usr/ports/lang/gcc6/Makefile (working copy) @@ -28,7 +28,7 @@ .endif CONFLICTS= gcc6-devel-6.* - +CFLAGS=-target x86_64-unknown-freebsd12.0 CPE_VENDOR= gnu GCC_VERSION= ${PORTVERSION} for use on an amd64 head context and I then attempt (as a means of testing, I normally use poudriere-devel ) portmaster -DK lang/gcc6 I still get: checking for x86_64-portbld-freebsd12.0-gcc... /wrkdirs/usr/ports/lang/gcc6/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc6/work/.build/./gcc/ -B/usr/local/x86_64-portbld-freebsd12.0/bin/ -B/usr/local/x86_64-portbld-freebsd12.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd12.0/include -isystem /usr/local/x86_64-portbld-freebsd12.0/sys-include checking for suffix of object files... configure: error: in `/wrkdirs/usr/ports/lang/gcc6/work/.build/x86_64-portbld-freebsd12.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. And the config.log still shows (from a recursive grep): /wrkdirs/usr/ports/lang/gcc6/work/.build/x86_64-portbld-freebsd12.0/libgcc/config.log:xgcc: error: unrecognized command line option '-target'; did you mean '-ftarget='? So one has to keep the CFLAGS as compatible with both clang and the xgcc that is used in the full bootstrap of gcc6 . Closing this PR, this port has been removed long ago. Also lang/gcc6 expired on 2020-02-29. I checked an gcc9 still has this build problem. I tested via a CFLAGS assigment in the Makefile, similar to comment 4. checking for x86_64-portbld-freebsd13.0-gcc... /wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/ -B/usr/local/x86_64-portbld-freebsd13.0/bin/ -B/usr/local/x86_64-portbld-freebsd13.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd13.0/include -isystem /usr/local/x86_64-portbld-freebsd13.0/sys-include -fno-checking checking for suffix of object files... configure: error: in `/wrkdirs/usr/ports/lang/gcc9/work/.build/x86_64-portbld-freebsd13.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details configure:3529: /wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/ -B/usr/local/x86_64-portbld-freebsd13.0/bin/ -B/usr/local/x86_64-portbld-freebsd13 .0/lib/ -isystem /usr/local/x86_64-portbld-freebsd13.0/include -isystem /usr/local/x86_64-portbld-freebsd13.0/sys-include -fno-checking -o conftest -O2 -target x86_64-unknown-freebsd13.0 -DLIBICONV_ PLUG -g -fno-strict-aliasing conftest.c >&5 xgcc: error: x86_64-unknown-freebsd13.0: No such file or directory xgcc: error: unrecognized command line option '-target' configure:3532: $? = 1 configure:3745: checking for suffix of object files configure:3767: /wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/ -B/usr/local/x86_64-portbld-freebsd13.0/bin/ -B/usr/local/x86_64-portbld-freebsd13 .0/lib/ -isystem /usr/local/x86_64-portbld-freebsd13.0/include -isystem /usr/local/x86_64-portbld-freebsd13.0/sys-include -fno-checking -c -O2 -target x86_64-unknown-freebsd13.0 -DLIBICONV_PLUG -g - fno-strict-aliasing conftest.c >&5 xgcc: error: x86_64-unknown-freebsd13.0: No such file or directory xgcc: error: unrecognized command line option '-target' configure:3771: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } (In reply to Rene Ladan from comment #5) lang/gcc9 still gets this problem so I updated the report to be based on gcc9 for now. Which binutils do you have installed? Isn't devel/binutils@amd64 (FLAVOR=amd64) necessary for the condition of comment #6? (In reply to Tatsuki Makino from comment #8) xgcc that reports the error is not from a binutils tool. Note that lang/gcc9/Makefile has: BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils RUN_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils which does not use an explicit flavor (no @amd64 present). This means that the devel/binutils used native as the flavor in its Makefile: FLAVORS= native aarch64 aarch64_none_elf amd64 arm_gnueabi arm_none_eabi \ avr i386 mingw32 mips mips64 powerpc powerpc64 riscv64 \ riscv64_none_elf s390x sparc64 riscv32_unknown_elf FLAVOR?= native So in use is devel/binutils, not devel/binutils@amd64 . But here is the binutils information for my context anyway: # pkg info "*binutils*" aarch64-binutils-2.33.1_2,1 aarch64-none-elf-binutils-2.33.1_2,1 amd64-binutils-2.33.1_2,1 binutils-2.33.1_2,1 powerpc-binutils-2.33.1_2,1 powerpc64-binutils-2.33.1_2,1 As for amd64, the two variants on the amd64 machine are: # pkg info amd64-binutils amd64-binutils-2.33.1_2,1 Name : amd64-binutils Version : 2.33.1_2,1 Installed on : Thu Jan 30 01:35:31 2020 PST Origin : devel/binutils Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : devel Licenses : GPLv3, LGPL3 Maintainer : bapt@FreeBSD.org WWW : https://www.gnu.org/software/binutils/ Comment : GNU binary tools Options : RELRO : off STATIC : off Annotations : FreeBSD_version: 1300075 cpe : cpe:2.3:a:gnu:binutils:2.33.1:::::freebsd13:x64:2 flavor : amd64 repo_type : binary repository : custom Flat size : 80.9MiB . . . # pkg info binutils binutils-2.33.1_2,1 Name : binutils Version : 2.33.1_2,1 Installed on : Thu Jan 30 01:34:52 2020 PST Origin : devel/binutils Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : devel Licenses : GPLv3, LGPL3 Maintainer : bapt@FreeBSD.org WWW : https://www.gnu.org/software/binutils/ Comment : GNU binary tools Options : NLS : on RELRO : off STATIC : off Shared Libs required: libintl.so.8 Annotations : FreeBSD_version: 1300075 cpe : cpe:2.3:a:gnu:binutils:2.33.1:::::freebsd13:x64:2 flavor : native repo_type : binary repository : custom Flat size : 658MiB . . . So both are avilable. xgcc is a temporary/intermediate compiler from the full bootstrap sequence. It does not support -target . System clang is used to build the first of the temporary/intermediate compilers. It does support -target . -target is not essential here: it is just an example of a command line option that is specific to clang to show what happens when such are used in CFLAGS. There may be more such options. Use of a command line option specific to xgcc or gcc9 would have problems at the clang stage. But I've not provided an example for such. Currently there is no means that I know of for keeping the options supplied to system clang vs. to xgcc distinct for the full bootstrap. Instead one must only use options that both support. Over to the maintainer. (In reply to Mark Millard from comment #9) > Currently there is no means that I know of for > keeping the options supplied to system clang vs. > to xgcc distinct for the full bootstrap. Instead > one must only use options that both support. This. I don't know how to tackle this realistically (and with reasonable effort) and suggest to close this unless someone wants to step up. Isn't this too a large extent a case of "Doktor, it hurts when I do X" - "Can you just not do X, then?" (In reply to Gerald Pfeifer from comment #11) > Isn't this too a large extent a case of "Doktor, it hurts when I do X" > - "Can you just not do X, then?" The problem is knowing up-front that X will lead to hurt or figuring out what X it was that caused the hurt or what to do that avoids X. It is not even obvious what command line options are common between xgcc and clang in various cases. But that does not imply that there is a reasonable solution. Ports supporting CFLAGS.gcc+= and CFLAGS.clang+= as a way to keep things separate would only help after figuring out that the split was needed and only would remove some of the problem for "what to do that avoids X" (because X would not have to be avoided). Status does not have a "no plan to fix" for Closed. I'm picking "Not Accepted" for now. Feel free to adjust if another selection is more appropriate. ^Triage: Update resolution. Not Accepted is usually used/reserved for issues with a concrete (or at least tangible) proposal (patch/review/idea) that are not accepted. The closest to this was comment 12 ("ports supporting CFLAGS.gcc+= and CFLAGS.clang+= ..."), but is not the the issue summary (Title/History) 'as stated' currently. Not Enough Information appears to be the most suitable, all else being equal, particularly given comment 11 ("I don't know how to tackle this realistically") To future viewers or interested parties, please re-open this issue if one can provide additional information and/or a change proposal that addresses the issue/report as stated |
I was doing a portupgrade lang/gcc6-devel based on make.conf as shown below (note the CFLAGS is for clang which is in use to build gcc6-devel): # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= WITH_DEBUG_FILES= MALLOC_PRODUCTION= TO_TYPE=armv6 TOOLS_TO_TYPE=arm-gnueabi VERSION_CONTEXT=11.0 CFLAGS+=-target ${TO_TYPE}--freebsd${VERSION_CONTEXT}-gnueabi -march=armv7-a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access .if ${.MAKE.LEVEL} == 0 CC=/usr/bin/clang CXX=/usr/bin/clang++ CPP=/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif The result was a failure from the CFLAGS being used for a . . . /work/build/./gcc/xgcc command during a configure activity: # more /usr/obj/portswork/usr/ports/lang/gcc6-devel/work/build/armv6-portbld-freebsd11.0/libgcc/config.log . . . configure:3653: checking for suffix of object files configure:3675: /usr/obj/portswork/usr/ports/lang/gcc6-devel/work/build/./gcc/xgcc -B/usr/obj/portswork/usr/ports/lang/gcc6-devel/work/build/./gcc/ -B/usr/local/armv6-portbld-freebsd11.0/bin/ -B/usr/l ocal/armv6-portbld-freebsd11.0/lib/ -isystem /usr/local/armv6-portbld-freebsd11.0/include -isystem /usr/local/armv6-portbld-freebsd11.0/sys-include -c -g -O2 -O -pipe -target armv6--freebsd11.0-gnu eabi -march=armv7-a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access -mfloat-abi=softfp -DLIBICONV_PLUG -fno-strict-aliasing conftest.c >&5 xgcc: error: armv6--freebsd11.0-gnueabi: No such file or directory xgcc: error: unrecognized command line option '-target'; did you mean '-ftarget='? configure:3679: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3693: error: in `/usr/obj/portswork/usr/ports/lang/gcc6-devel/work/build/armv6-portbld-freebsd11.0/libgcc': configure:3696: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. . . . That results in the overall make aborting: checking for suffix of object files... configure: error: in `/usr/obj/portswork/usr/ports/lang/gcc6-devel/work/build/armv6-portbld-freebsd11.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. Makefile:11385: recipe for target 'configure-target-libgcc' failed gmake[3]: *** [configure-target-libgcc] Error 1 gmake[3]: *** Waiting for unfinished jobs.... . . . gmake[3]: Leaving directory '/usr/obj/portswork/usr/ports/lang/gcc6-devel/work/build' Makefile:876: recipe for target 'all' failed gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory '/usr/obj/portswork/usr/ports/lang/gcc6-devel/work/build' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/lang/gcc6-devel *** Error code 1 I will try others styles of having CFLAGS in make.conf but I figured I'd report about make.conf polluting the internal configuration tests during the gcc6-devel build. (Possibly true of building other gccN's?)