Date: Wed, 12 May 2021 23:25:54 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD ports <freebsd-ports@freebsd.org> Subject: Re: Troubles compiling lxqt on RPi4 [out of date Mk/Uses/meson.mk in use] Message-ID: <29ABCAE7-7A44-4A6E-9B9E-C92D4C30444A@yahoo.com> In-Reply-To: <D6F9A3D7-D313-4218-8DD5-B97229C0DA3C@yahoo.com> References: <E4E579C2-8BE4-4A4E-B7A1-C4F18E297A75.ref@yahoo.com> <E4E579C2-8BE4-4A4E-B7A1-C4F18E297A75@yahoo.com> <20210513034811.GA40952@www.zefox.net> <C229B27A-8AAA-4ED9-A57D-AA271934FEEE@yahoo.com> <20210513052831.GA41156@www.zefox.net> <D6F9A3D7-D313-4218-8DD5-B97229C0DA3C@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-12, at 23:13, Mark Millard <marklmi at yahoo.com> wrote: >=20 > On 2021-May-12, at 22:28, bob prohaska <fbsd at www.zefox.net> wrote: >=20 >> 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 <fbsd@www.zefox.net> wrote: >>>=20 >>>>=20 >>>> Moving to /usr/ports/json-glib and using=20 >>>> make -DBATCH MAKE_JOBS_UNSAFE=3Dyes MAKE_JOBS_NUMBER=3D4 = DISABLE_VULNERABILITIES=3Dyes > make.log >>>> reports several instances of=20 >>>> error: unknown argument: '-fno-color-diagnostics' >>>>=20 >>>> Running make clean and restarting makes no difference. There don't = seem to be >>>> any user options for making json-glib, >>>=20 >>> The build log at: >>>=20 >>> = http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb= 8d11b0/logs/json-glib-1.6.2_1.log >>>=20 >>> is the one that just python38 and it reports: >>>=20 >>> ---Begin OPTIONS List--- >>> =3D=3D=3D> The following configuration options are available for = json-glib-1.6.2_1: >>> DOCS=3Don: Build and/or install documentation >>> GIR=3Don: Build introspection data >>> =3D=3D=3D> Use 'make config' to modify these settings >>> ---End OPTIONS List--- >>>=20 >>> 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). >>>=20 >>=20 >> Turning off both options and trying a manual make seems to end with = the same error. >>=20 >>=20 >>=20 >>>> but I wonder if it might be inherting >>>> an incompatible option from something else. >>>=20 >>> That build log also has lines showing the likes of: >>>=20 >>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . = -fno-color-diagnostics . . . >>>=20 >>> The compiler is reported in the log to be: >>>=20 >>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang = version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe)") >>> C linker for the host machine: cc ld.lld 11.0.1 >>>=20 >>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my >>> historical main [so: 14] environments. >>>=20 >>> So system-clang apparently allows the option. >>>=20 >>> 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. >>>=20 >>>=20 >>=20 >> A copy of the make log is at >> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log >=20 > Note: Your environment is not up to date enough to be using > python38 . The log shows: >=20 > [ 1% 4/69] /usr/local/bin/python3.7 . . . > . . . >=20 > I'll note that /usr/ports/UPDATING reports: >=20 > 20210425: > AFFECTS: users of python > AUTHOR: kai@FreeBSD.org >=20 > The default version of python3 and python was switched to 3.8. >=20 > For ports users wanting to keep version 3.7 as default, > add DEFAULT_VERSIONS+=3D python=3D3.7 python3=3D3.7 to make.conf >=20 > Following procedures may ease the upgrade: >=20 > 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 >=20 > For portmaster users: > # sh > # portmaster -o lang/python38 python37 > # REINSTALL=3D"$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')" > # pkg delete -f "*py37*" > # portmaster $REINSTALL > # REBUILD=3D$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | = cut -d : -f 1 | sort -u) > # portmaster $REBUILD > # REBUILD2=3D$(pkg list | grep python-37 | xargs pkg which | awk = '{print $6}' | sort -u) > # portmaster $REBUILD2 >=20 >=20 >=20 > The log also shows the use of -Xclang in the cc commands: >=20 > cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang = -fno-color-diagnostics . . . >=20 > but: >=20 > = http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb= 8d11b0/logs/json-glib-1.6.2_1.log >=20 > does not show any use of -Xclang . >=20 > -Xclang makes the following argument be passed directly to the > cc1 compiler stage. So the: >=20 > error: unknown argument: '-fno-color-diagnostics' >=20 > would be from cc1. "clang -cc1 --help" only reports one > form of color-diagnostics option allowed by the -cc1 > stage: >=20 > -fcolor-diagnostics Enable colors in diagnostics >=20 > Viewed various ways that confirm: >=20 > # more main.c > static volatile char big_area[67001] =3D "This is a test"; > int main () > { > big_area[67000] =3D '9'; > } >=20 > # clang -Xclang -fno-color-diagnostics main.c > error: unknown argument: '-fno-color-diagnostics' >=20 > But the detail of what is involved, showing the > -cc1 command that is internally generated, is: >=20 > # clang -### -Xclang -fno-color-diagnostics main.c > FreeBSD clang version 11.0.1 (git@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=3Dall" "-fno-rounding-math" = "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" = "-fno-split-dwarf-inlining" "-debugger-tuning=3Dgdb" "-resource-dir" = "/usr/lib/clang/11.0.1" "-fdebug-compilation-dir" "/root/c_tests" = "-ferror-limit" "19" "-fgnuc-version=3D4.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=3Dboth" = "--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" >=20 > Another way: >=20 > # clang -cc1 -fno-color-diagnostics > error: unknown argument: '-fno-color-diagnostics' >=20 > 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. >=20 >>> Do you have /etc/make.conf or /etc/src.conf or the like that >>> might be interfering? Something else? >>>=20 >> Neither file is present. >>=20 >>> What does "cc -v" show in your context? >>>=20 >> bob@nemesis:/usr/ports/devel/json-glib % cc -v >> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) >> Target: aarch64-unknown-freebsd14.0 >> Thread model: posix >> InstalledDir: /usr/bin >>=20 >>=20 >>> FYI: >>> As I remember, "-DBATCH MAKE_JOBS_UNSAFE=3Dyes MAKE_JOBS_NUMBER=3D4" >>> is incoherent: the first says not to do the last. >>>=20 >> Not sure I follow; -DBATCH refers to config options, would that = affect job number? >=20 > I should not have included "-DBATCH" in my wording. So: >=20 > As I remember, "MAKE_JOBS_UNSAFE=3Dyes MAKE_JOBS_NUMBER=3D4" > is incoherent: the first says not to do the last. >=20 >> 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=20 >> would be easier to encounter incompatibilities. If a global "make = clean" will >> simplify things it'll be worth the wait. >=20 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=3Dff2796d5bc83 shows: QUOTE author Tobias Kortkamp <tobik@FreeBSD.org> 2021-04-08 09:33:03 = +0000 committer Tobias Kortkamp <tobik@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 =3D { +- '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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29ABCAE7-7A44-4A6E-9B9E-C92D4C30444A>