Date: Wed, 12 May 2021 23:13:06 -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 Message-ID: <D6F9A3D7-D313-4218-8DD5-B97229C0DA3C@yahoo.com> In-Reply-To: <20210513052831.GA41156@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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 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: kai@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+=3D python=3D3.7 python3=3D3.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=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 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_sd1cb= 8d11b0/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] =3D "This is a test"; int main () { big_area[67000] =3D '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 (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" 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? >>=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? I should not have included "-DBATCH" in my wording. So: As I remember, "MAKE_JOBS_UNSAFE=3Dyes MAKE_JOBS_NUMBER=3D4" 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=20 > would be easier to encounter incompatibilities. If a global "make = clean" will > simplify things it'll be worth the wait. =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?D6F9A3D7-D313-4218-8DD5-B97229C0DA3C>