Missing build for Linux 386

[Integralist]

Originally reported by @epolish fastly/cli#419.

Summary:
When using the Fastly CLI it reports an error when trying to download a version of Viceroy for the Linux OS and 386 Arch. This is because there is no such build in the Viceroy release.

[tschneidereit]

Unfortunately this isn't something we'll be able to fix anytime soon: Viceroy's WebAssembly runtime, Wasmtime, doesn't have a 386 codegen backend, so it only works on x86_64. It's possible that that will change at some point, but nobody actively has plans to work on it, AFAIK.

[epolish]

So, it won't be issued in foreseeable future for Linux, right?

[tschneidereit]

Sadly no, we won't be able to provide a 32bit x86 build anytime soon.

[epolish]

Okay(
Thank you, anyway!

[epolish]

I've just checked my os

$ uname -m
x86_64

$ arch
x86_64

$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 6
On-line CPU(s) list: 0-5
Thread(s) per core: 1
Core(s) per socket: 6
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz
Stepping: 10
CPU MHz: 800.004
CPU max MHz: 4000.0000
CPU min MHz: 800.0000
BogoMIPS: 5599.85
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 9216K
NUMA node0 CPU(s): 0-5
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 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

[epolish]

So that's strange how it could be 386

[tschneidereit]

oh, that's interesting indeed! Are you running a 64bit operating system, too?

[Integralist]

Might be worth checking uname -p (i.e. "print the machine processor architecture name").

[epolish]

~$ uname -p
x86_64

I've already posted it in the previous comment

[epolish]

Yep, Os and Proc are all the same 64-bit

[epolish]

Any thoughts on this, guys?

[aturon]

I know the CLI issue was already closed, but that was before realizing you were on an x86_64 machine. I think the problem isn't in Viceroy, but rather something in how the CLI is determining the architecture.

@Integralist could you re-open the issue on the CLI repo and look at things on that side?

[cratelyn]

I know the CLI issue was already closed, but that was before realizing you were on an x86_64 machine. I think the problem isn't in Viceroy, but rather something in how the CLI is determining the architecture.

@Integralist could you re-open the issue on the CLI repo and look at things on that side?

https://github.com/fastly/cli/blob/42d837799842c0b07ddc1c8ec436ecd7197b7f23/pkg/commands/compute/serve.go#L130

hazarding a guess here, it looks like the architecture is determined through runtime.GOARCH. is it possible that this could be incorrectly reporting a 32-bit architecture for some reason?

in any case, i agree with @aturon's assessment above that the problem isn't in Viceroy itself.

[Integralist]

This was discussed internally earlier with @tschneidereit and the runtime package is provided by the Go language and so there's not much we can do to fix an issue there (other than reporting an issue on their issue tracker).

I would feel uncomfortable trying to write custom logic in the CLI when the go team have provided specific APIs for exactly this use case.

[phamann]

@epolish @Integralist et.al - apologies for joining the discussion late, however, I think I know whats going on here 😄.

The Fastly CLI is written in Go; and the values of Go’s runtime.GOOS and runtime.GOARCH constants are recorded at compile time and represent the target architecture and are not runtime values that represent the host machine architecture.

GOARCH, GOOS, and GOROOT are recorded at compile time and made available by constants or functions in this package, but they do not influence the execution of the run-time system.
(taken from: https://pkg.go.dev/runtime)

This would suggest that @epolish is using a 386 build of the Fastly CLI on an x86 machine, which would still work.

Therefore, @epolish, I would suggest that you reinstall the CLI using the correct architecture for your x86 system. The binaries can be found on each release page, for example the latest release has linux_amd64 binaries in various package formats for your machine and can be found here: https://github.com/fastly/cli/releases/tag/v0.39.1

You should then be able to run fastly compute serve successfully. Hope that helps!

[epolish]

Hello team!
Sorry for the delay..
And thanks for the answers!
I'll try them asap and keep you posted

[epolish]

@phamann you were totally right!
I installed fastly cli from 386 source
But as soon as I installed from amd64 all works just fine, thanks!
But unfortunately, I have the next issue
ERROR: error during execution process:
/home/eugene/.config/fastly/viceroy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /home/eugene/.config/fastly/viceroy).
I have GLIBC_2.27 now, and I just cannot re-build it to GLIBC_2.29 because I'm on Ubuntu 18 now
and as soon as I upgrade GLIBC to GLIBC_2.29 I'll broke my system totally :D
So the issue can be solved only with upgrading to Ubuntu 19 or 20..
But thanks anyway!