Troubles compiling lxqt on RPi4

Thu May 13 06:13:18 UTC 2021

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 at 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 (git at 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: kai at 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 (git at 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 at nemesis:/usr/ports/devel/json-glib % cc -v
> FreeBSD clang version 11.0.1 (git at 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)