Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PROPOSAL: Remove 32-bit binaries from the distribution (Linux and Windows) #2461

Closed
tlimoncelli opened this issue Jun 25, 2023 · 2 comments · Fixed by #2524
Closed

PROPOSAL: Remove 32-bit binaries from the distribution (Linux and Windows) #2461

tlimoncelli opened this issue Jun 25, 2023 · 2 comments · Fixed by #2524

Comments

@tlimoncelli
Copy link
Contributor

tlimoncelli commented Jun 25, 2023

Is your feature request related to a problem? Please describe.

Is anyone still using 32-bit binaries? I propose we remove them from the distribution. Folks have until Sept 10 to speak up if they are still needed.

Specifically, we'll remove the following builds:

    • building                                       binary=dist/build_linux_386/dnscontrol
    • building                                       binary=dist/build_windows_386/dnscontrol.exe
    • building                                       binary=dist/build_freebsd_386/dnscontrol

Why?

  • It slows down build times (testing finds it will reduce builds from ~11 to ~8 minutes)
  • We don't believe they are used.

NOTE: The code should still build for 32-bit systems. We don't do anything to prevent someone from doing their own 32-bit builds.

Describe the solution you'd like

No longer build 32-bit binaries.

Describe alternatives you've considered
n/a

Additional context
n/a

@tlimoncelli
Copy link
Contributor Author

tlimoncelli commented Jun 25, 2023

Compare the build time for:

@Firefishy
Copy link
Contributor

Firefishy commented Jul 18, 2023

The 386 docker build immediately throws a segfault for me (under emulation) ;-) No loss

 % docker run --platform linux/386 ghcr.io/stackexchange/dnscontrol:4.1.1 version
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x4f0 pc=0x808dfbf]

runtime stack:
runtime.throw({0x938205a, 0x2a})
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/panic.go:1047 +0x4d fp=0x40800da0 sp=0x40800d8c pc=0x807e41d
runtime.sigpanic()
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/signal_unix.go:821 +0x2b8 fp=0x40800db8 sp=0x40800da0 pc=0x8094698
runtime.runqput(0x0, 0xa0063c0, 0x1)
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/proc.go:5969 +0xaf fp=0x40800dd8 sp=0x40800db8 pc=0x808dfbf
runtime.newproc.func1()
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/proc.go:4248 +0x56 fp=0x40800dec sp=0x40800dd8 pc=0x8089be6
runtime.systemstack()
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/asm_386.s:370 +0x41 fp=0x40800df0 sp=0x40800dec pc=0x80ada31

goroutine 1 [running, locked to thread]:
	goroutine running on other thread; stack unavailable

goroutine 2 [runnable]:
runtime.forcegchelper()
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/proc.go:296 fp=0xa04bff0 sp=0xa04bfec pc=0x80812c0
runtime.goexit()
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/asm_386.s:1326 +0x1 fp=0xa04bff4 sp=0xa04bff0 pc=0x80aedc1
created by runtime.init.5
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/proc.go:293 +0x23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants