Bug 207125

Summary: lang/gcc6-devel: (clang used to build) CFLAGS for clang stop portupgrade lang/gcc6-devel
Product: Ports & Packages Reporter: Mark Millard <marklmi26-fbsd>
Component: Individual Port(s)Assignee: freebsd-ports-bugs mailing list <ports-bugs>
Status: Open ---    
Severity: Affects Only Me CC: gerald, miwi
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   

Description Mark Millard 2016-02-12 08:56:05 UTC
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
CFLAGS+=-target ${TO_TYPE}--freebsd${VERSION_CONTEXT}-gnueabi -march=armv7-a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access
.if ${.MAKE.LEVEL} == 0
.export CC
.export CXX
.export CPP

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_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

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?)
Comment 1 Mark Millard 2016-06-13 06:12:08 UTC
(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.)
Comment 2 Gerald Pfeifer freebsd_committer 2016-06-13 11:28:15 UTC
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).
Comment 3 Martin Wilke freebsd_committer 2018-05-10 16:05:40 UTC

Is this problem still relevant?
Comment 4 Mark Millard 2018-05-12 05:53:46 UTC
(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 @@

 CONFLICTS=     gcc6-devel-6.*
+CFLAGS=-target x86_64-unknown-freebsd12.0
 CPE_VENDOR=    gnu


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 .