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. === 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"
