Bug 207125 - lang/gcc9: (clang used to build) CFLAGS for clang stops portmaster lang/gcc9 build
Summary: lang/gcc9: (clang used to build) CFLAGS for clang stops portmaster lang/gcc9 ...
Status: Closed Not Enough Information
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2016-02-12 08:56 UTC by Mark Millard
Modified: 2020-06-19 03:09 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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
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?)
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 freebsd_triage 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 freebsd_triage 2018-05-10 16:05:40 UTC
Hey,

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 @@
 .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 .
Comment 5 Rene Ladan freebsd_committer freebsd_triage 2020-03-07 12:25:13 UTC
Closing this PR, this port has been removed long ago. Also lang/gcc6 expired on 2020-02-29.
Comment 6 Mark Millard 2020-03-07 20:11:41 UTC
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;
| }
Comment 7 Mark Millard 2020-03-07 20:14:23 UTC
(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.
Comment 8 Tatsuki Makino 2020-03-08 05:27:03 UTC
Which binutils do you have installed?
Isn't devel/binutils@amd64 (FLAVOR=amd64) necessary for the condition of comment #6?
Comment 9 Mark Millard 2020-03-08 17:26:09 UTC
(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.
Comment 10 Li-Wen Hsu freebsd_committer freebsd_triage 2020-06-16 23:09:37 UTC
Over to the maintainer.
Comment 11 Gerald Pfeifer freebsd_committer freebsd_triage 2020-06-18 20:51:46 UTC
(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?"
Comment 12 Mark Millard 2020-06-18 21:09:20 UTC
(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.
Comment 13 Kubilay Kocak freebsd_committer freebsd_triage 2020-06-19 03:09:12 UTC
^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