On 2021-May-12, at 23:13, Mark Millard <marklmi at yahoo.com> wrote:
> > On 2021-May-12, at 22:28, bob prohaska <fbsd at www.zefox.net> wrote: > >> On Wed, May 12, 2021 at 09:16:29PM -0700, Mark Millard via freebsd-ports >> wrote: >>> On 2021-May-12, at 20:48, bob prohaska <f...@www.zefox.net> wrote: >>> >>>> >>>> Moving to /usr/ports/json-glib and using >>>> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 >>>> DISABLE_VULNERABILITIES=yes > make.log >>>> reports several instances of >>>> error: unknown argument: '-fno-color-diagnostics' >>>> >>>> Running make clean and restarting makes no difference. There don't seem to >>>> be >>>> any user options for making json-glib, >>> >>> The build log at: >>> >>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log >>> >>> is the one that just python38 and it reports: >>> >>> ---Begin OPTIONS List--- >>> ===> The following configuration options are available for >>> json-glib-1.6.2_1: >>> DOCS=on: Build and/or install documentation >>> GIR=on: Build introspection data >>> ===> Use 'make config' to modify these settings >>> ---End OPTIONS List--- >>> >>> as the options that were used for the build. So >>> there are 2 options, one of which is appearently >>> tied to the code's operation (introspection data). >>> >> >> Turning off both options and trying a manual make seems to end with the same >> error. >> >> >> >>>> but I wonder if it might be inherting >>>> an incompatible option from something else. >>> >>> That build log also has lines showing the likes of: >>> >>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . >>> -fno-color-diagnostics . . . >>> >>> The compiler is reported in the log to be: >>> >>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version >>> 11.0.1 (g...@github.com:llvm/llvm-project.git >>> llvmorg-11.0.1-0-g43ff75f2c3fe)") >>> C linker for the host machine: cc ld.lld 11.0.1 >>> >>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my >>> historical main [so: 14] environments. >>> >>> So system-clang apparently allows the option. >>> >>> You did not show any example command that got the complaint >>> about -fno-color-diagnostics so I can ont even be sure it >>> was a cc command that had the option. >>> >>> >> >> A copy of the make log is at >> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log > > Note: Your environment is not up to date enough to be using > python38 . The log shows: > > [ 1% 4/69] /usr/local/bin/python3.7 . . . > . . . > > I'll note that /usr/ports/UPDATING reports: > > 20210425: > AFFECTS: users of python > AUTHOR: k...@freebsd.org > > The default version of python3 and python was switched to 3.8. > > For ports users wanting to keep version 3.7 as default, > add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf > > Following procedures may ease the upgrade: > > For users of pre-build packages: > # sh > # for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-}; > done > # pkg upgrade > > For portmaster users: > # sh > # portmaster -o lang/python38 python37 > # REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')" > # pkg delete -f "*py37*" > # portmaster $REINSTALL > # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : > -f 1 | sort -u) > # portmaster $REBUILD > # REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' > | sort -u) > # portmaster $REBUILD2 > > > > The log also shows the use of -Xclang in the cc commands: > > cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang > -fno-color-diagnostics . . . > > but: > > http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log > > does not show any use of -Xclang . > > -Xclang makes the following argument be passed directly to the > cc1 compiler stage. So the: > > error: unknown argument: '-fno-color-diagnostics' > > would be from cc1. "clang -cc1 --help" only reports one > form of color-diagnostics option allowed by the -cc1 > stage: > > -fcolor-diagnostics Enable colors in diagnostics > > Viewed various ways that confirm: > > # more main.c > static volatile char big_area[67001] = "This is a test"; > int main () > { > big_area[67000] = '9'; > } > > # clang -Xclang -fno-color-diagnostics main.c > error: unknown argument: '-fno-color-diagnostics' > > But the detail of what is involved, showing the > -cc1 command that is internally generated, is: > > # clang -### -Xclang -fno-color-diagnostics main.c > FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git > llvmorg-11.0.1-0-g43ff75f2c3fe) > Target: x86_64-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-freebsd14.0" "-emit-obj" > "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" > "-main-file-name" "main.c" "-mrelocation-model" "static" > "-mframe-pointer=all" "-fno-rounding-math" "-mconstructor-aliases" > "-munwind-tables" "-target-cpu" "x86-64" "-fno-split-dwarf-inlining" > "-debugger-tuning=gdb" "-resource-dir" "/usr/lib/clang/11.0.1" > "-fdebug-compilation-dir" "/root/c_tests" "-ferror-limit" "19" > "-fgnuc-version=4.2.1" "-fcolor-diagnostics" "-fno-color-diagnostics" > "-faddrsig" "-o" "/tmp/main-496b10.o" "-x" "c" "main.c" > "/usr/local/bin/x86_64-unknown-freebsd14.0-ld" "--eh-frame-hdr" > "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" > "--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" > "/usr/lib/crtbegin.o" "-L/usr/lib" "/tmp/main-496b10.o" "-lgcc" "--as-needed" > "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" > > Another way: > > # clang -cc1 -fno-color-diagnostics > error: unknown argument: '-fno-color-diagnostics' > > So the question becomes how -Xclang got involved. > I do not know yet. It is not explicit in the > Makefile . It is not obvious where to look. > >>> Do you have /etc/make.conf or /etc/src.conf or the like that >>> might be interfering? Something else? >>> >> Neither file is present. >> >>> What does "cc -v" show in your context? >>> >> bob@nemesis:/usr/ports/devel/json-glib % cc -v >> FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git >> llvmorg-11.0.1-0-g43ff75f2c3fe) >> Target: aarch64-unknown-freebsd14.0 >> Thread model: posix >> InstalledDir: /usr/bin >> >> >>> FYI: >>> As I remember, "-DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4" >>> is incoherent: the first says not to do the last. >>> >> Not sure I follow; -DBATCH refers to config options, would that affect job >> number? > > I should not have included "-DBATCH" in my wording. So: > > As I remember, "MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4" > is incoherent: the first says not to do the last. > >> The last major port compiled was www/chromium, might there be some cleanup >> required >> before starting another compilation? I've always thought that ports >> communicated only >> through installed files, but if they use one another's source or object >> files it >> would be easier to encounter incompatibilities. If a global "make clean" >> will >> simplify things it'll be worth the wait. > Various ports broke for the same -Xclang -no-color-diagnostics . They all used devel/meson --which was fixed back on 2021-04-20: https://cgit.freebsd.org/ports/commit/?id=ff2796d5bc83 shows: QUOTE author Tobias Kortkamp <to...@freebsd.org> 2021-04-08 09:33:03 +0000 committer Tobias Kortkamp <to...@freebsd.org> 2021-04-20 06:57:35 +0000 commit ff2796d5bc837b0c6cb26791439c64f96fe1c090 (patch) . . . Mk/Uses/meson.mk: Do not force color output (D29353) END QUOTE Part of the change was: + clang_color_args = { +- 'auto': ['-Xclang', '-fcolor-diagnostics'], +- 'always': ['-Xclang', '-fcolor-diagnostics'], +- 'never': ['-Xclang', '-fno-color-diagnostics'], ++ 'auto': ['-fcolor-diagnostics'], ++ 'always': ['-fcolor-diagnostics'], ++ 'never': ['-fno-color-diagnostics'], + } # type: T.Dict[str, T.List[str]] that replaces the incorrect combination of -Xclang with -fno-color-diagnostics (and more) So: Update your environment to have the fix. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
