bug#56353: sbcl-2.2.6 build fail

bug#56353: sbcl-2.2.6 build fail

[Wensheng Xie]

Hi, guix:

the command:
guix package -u

log:
/gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv wird erstellt …
- „build-doc“-Phasebuilder for `/gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv' failed with exit code 1
Erstellung von /gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv fehlgeschlagen
Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
guix package: Fehler: build of
`/gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv' failed

This is what I had right. If you need more, please let me know.

best regards
wxie

bug#56353: sbcl-2.2.6 build fail

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.


This log file is always a good idea to include.

If it's more than a few hundred kilobytes compressed, send only the last ~300K or so.
Hi,

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#56353: sbcl-2.2.6 build fail

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]


Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
>
>
> This log file is always a good idea to include.

I think this is the equivalent non-grafted derivation:

  https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv

There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
get it to build successfully once though on my laptop.

Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
successfully, or if there's particular conditions for it to build?

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#56353: sbcl-2.2.6 build fail

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 4092 bytes --]

Christopher Baines <mail@cbaines.net> skribis:

> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>
>> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
>>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
>>
>>
>> This log file is always a good idea to include.
>
> I think this is the equivalent non-grafted derivation:
>
>   https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
>
> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
> get it to build successfully once though on my laptop.
>
> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
> successfully, or if there's particular conditions for it to build?
>
> Thanks,
>
> Chris

According to the logs, the 'build-doc' phase fails to compile the
documentation for SIMD related functions. There's a patch disabling this
part of the doc unless we compile on x86_64, but maybe not all x86_64
CPUs have the required instructions...

Would it be possible to get the result of "lscpu" on some machines where
it fails?

The build always works on my machine:
--8<---------------cut here---------------start------------->8---
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  32
  On-line CPU(s) list:   0-31
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 9 5950X 16-Core Processor
    CPU family:          25
    Model:               33
    Thread(s) per core:  2
    Core(s) per socket:  16
    Socket(s):           1
    Stepping:            0
    Frequency boost:     enabled
    CPU max MHz:         5083.3979
    CPU min MHz:         2200.0000
    BogoMIPS:            6786.83
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_go
                         od nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy sv
                         m extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate
                          ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc c
                         qm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists paus
                         efilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   512 KiB (16 instances)
  L1i:                   512 KiB (16 instances)
  L2:                    8 MiB (16 instances)
  L3:                    64 MiB (2 instances)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-31
Vulnerabilities:         
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling
  Srbds:                 Not affected
  Tsx async abort:       Not affected
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#56353: sbcl-2.2.6 build fail

[Christopher Baines]

[-- Attachment #1.1: Type: text/plain, Size: 1416 bytes --]


Guillaume Le Vaillant <glv@posteo.net> writes:

> [[PGP Signed Part:Undecided]]
> Christopher Baines <mail@cbaines.net> skribis:
>
>> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>>
>>> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
>>>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
>>>
>>>
>>> This log file is always a good idea to include.
>>
>> I think this is the equivalent non-grafted derivation:
>>
>>   https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
>>
>> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
>> get it to build successfully once though on my laptop.
>>
>> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
>> successfully, or if there's particular conditions for it to build?
>>
>> Thanks,
>>
>> Chris
>
> According to the logs, the 'build-doc' phase fails to compile the
> documentation for SIMD related functions. There's a patch disabling this
> part of the doc unless we compile on x86_64, but maybe not all x86_64
> CPUs have the required instructions...
>
> Would it be possible to get the result of "lscpu" on some machines where
> it fails?

Sure, here is the lscpu output from the bayfront and harbourfront
machines.


[-- Attachment #1.2: bayfront lscpu output --]
[-- Type: text/plain, Size: 2303 bytes --]

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  32
  On-line CPU(s) list:   0-31
Vendor ID:               AuthenticAMD
  Model name:            AMD Opteron(tm) Processor 6278
    CPU family:          21
    Model:               1
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           2
    Stepping:            2
    Frequency boost:     enabled
    CPU max MHz:         2400.0000
    CPU min MHz:         1400.0000
    BogoMIPS:            4799.96
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_go
                         od nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legac
                         y abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall arat npt lbrv svm_lock nrip_save ts
                         c_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   512 KiB (32 instances)
  L1i:                   1 MiB (16 instances)
  L2:                    32 MiB (16 instances)
  L3:                    24 MiB (4 instances)
NUMA:                    
  NUMA node(s):          4
  NUMA node0 CPU(s):     0-7
  NUMA node1 CPU(s):     8-15
  NUMA node2 CPU(s):     16-23
  NUMA node3 CPU(s):     24-31
Vulnerabilities:         
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Full AMD retpoline, STIBP disabled, RSB filling
  Srbds:                 Not affected
  Tsx async abort:       Not affected

[-- Attachment #1.3: harbourfront lscpu --]
[-- Type: text/plain, Size: 1685 bytes --]

Architecture:           x86_64
  CPU op-mode(s):       32-bit, 64-bit
  Address sizes:        38 bits physical, 48 bits virtual
  Byte Order:           Little Endian
CPU(s):                 8
  On-line CPU(s) list:  0-7
Vendor ID:              GenuineIntel
  Model name:           Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
    CPU family:         6
    Model:              23
    Thread(s) per core: 1
    Core(s) per socket: 4
    Socket(s):          2
    Stepping:           10
    BogoMIPS:           4987.55
    Flags:              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts 
                        rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm pti dtherm
Caches (sum of all):    
  L1d:                  256 KiB (8 instances)
  L1i:                  256 KiB (8 instances)
  L2:                   24 MiB (4 instances)
NUMA:                   
  NUMA node(s):         1
  NUMA node0 CPU(s):    0-7
Vulnerabilities:        
  Itlb multihit:        KVM: Mitigation: VMX unsupported
  L1tf:                 Mitigation; PTE Inversion
  Mds:                  Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
  Meltdown:             Mitigation; PTI
  Spec store bypass:    Vulnerable
  Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:           Mitigation; Full generic retpoline, STIBP disabled, RSB filling
  Srbds:                Not affected
  Tsx async abort:      Not affected

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#56353: sbcl-2.2.6 build fail

[bokr]

Hi,

On +2022-07-02 20:26:40 +0100, Christopher Baines wrote:
> 
> Guillaume Le Vaillant <glv@posteo.net> writes:
> 
> > [[PGP Signed Part:Undecided]]
> > Christopher Baines <mail@cbaines.net> skribis:
> >
> >> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
> >>
> >>> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
> >>>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
> >>>
> >>>
> >>> This log file is always a good idea to include.
> >>
> >> I think this is the equivalent non-grafted derivation:
> >>
> >>   https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
> >>
> >> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
> >> get it to build successfully once though on my laptop.
> >>
> >> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
> >> successfully, or if there's particular conditions for it to build?
> >>
> >> Thanks,
> >>
> >> Chris
> >
> > According to the logs, the 'build-doc' phase fails to compile the
> > documentation for SIMD related functions. There's a patch disabling this
> > part of the doc unless we compile on x86_64, but maybe not all x86_64
> > CPUs have the required instructions...
> >
> > Would it be possible to get the result of "lscpu" on some machines where
> > it fails?
> 
> Sure, here is the lscpu output from the bayfront and harbourfront
> machines.
> 
[...]

I wonder what running this at the time builds failed would have shown:

--8<---------------cut here---------------start------------->8---
#/usr/bin/bash
# ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??)
top -n 1 | \
sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
    -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
    -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
--8<---------------cut here---------------end--------------->8---
(no guarantees on my hack to get rid of the highlighting escapes
and utf8->ascii quote subst :)
(top seems to assume even -n 1 output is always going to interactive dest)

Anyway, wondering: Could memory and CPU loading at the time
have triggered the build failure?
--
Regards,
Bengt Richter

bug#56353: sbcl-2.2.6 build fail

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

bokr@bokr.com skribis:

> I wonder what running this at the time builds failed would have shown:
>
> #/usr/bin/bash
> # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??)
> top -n 1 | \
> sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
>     -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
>     -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
>
> (no guarantees on my hack to get rid of the highlighting escapes
> and utf8->ascii quote subst :)
> (top seems to assume even -n 1 output is always going to interactive dest)
>
> Anyway, wondering: Could memory and CPU loading at the time
> have triggered the build failure?

I don't think so. It looks like the SB-SIMD optional module only gets
built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and
Harbourfront machines don't, and this is why the 'build-doc' phase fails
when trying to load SB-SIMD to compile its documentation.

I'm testing a patch disabling SB-SIMD, and I'll push it if all goes
well.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#56353: sbcl-2.2.6 build fail

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

Guillaume Le Vaillant <glv@posteo.net> skribis:

> bokr@bokr.com skribis:
>
>> I wonder what running this at the time builds failed would have shown:
>>
>> #/usr/bin/bash
>> # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??)
>> top -n 1 | \
>> sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
>>     -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
>>     -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
>>
>> (no guarantees on my hack to get rid of the highlighting escapes
>> and utf8->ascii quote subst :)
>> (top seems to assume even -n 1 output is always going to interactive dest)
>>
>> Anyway, wondering: Could memory and CPU loading at the time
>> have triggered the build failure?
>
> I don't think so. It looks like the SB-SIMD optional module only gets
> built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and
> Harbourfront machines don't, and this is why the 'build-doc' phase fails
> when trying to load SB-SIMD to compile its documentation.
>
> I'm testing a patch disabling SB-SIMD, and I'll push it if all goes
> well.

Patch pushed as e0d2f8164e6a1c15fdcae6f7dadb05c0c9e25352.
Closing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]