github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Build failure on i386 for v1.9 #3725

New Issue
Closed
opened 2025-11-02 05:23:09 -06:00 by GiteaMirror · 9 comments
GiteaMirror commented 2025-11-02 05:23:09 -06:00
Owner
Copy Link

Originally created by @lovett on GitHub (Aug 4, 2019).

I'm trying to build v1.9 from source on i386, but make fails and I'm not sure why.

My golang version is 1.11.5. I'm building from source rather than using the standard prebuilt binary for i386 because my hardware is very old, and the prebuilt binary fails with an illegal instruction error most likely related to not having SSE2. I was able to build gitea up to v1.8 successfully using golang 1.10. The error is new as of v1.9.

I'm invoking Make like this:
TAGS="bindata sqlite redis" make generate build

It's failing like this:

github.com/chaseadamsio/goorgeous
Makefile:315: recipe for target 'gitea' failed
make: *** [gitea] Error 1

I can't tell whether goorgeous is where the failure happens, or if it's whatever comes after it.

I realize old hardware compatibility isn't exactly something to shed tears over, but I'd be interested in any ideas if this seems fixable.

Originally created by @lovett on GitHub (Aug 4, 2019). I'm trying to build v1.9 from source on i386, but `make` fails and I'm not sure why. My golang version is 1.11.5. I'm building from source rather than using the standard prebuilt binary for i386 because my hardware is very old, and the prebuilt binary fails with an illegal instruction error most likely related to not having SSE2. I was able to build gitea up to v1.8 successfully using golang 1.10. The error is new as of v1.9. I'm invoking Make like this: `TAGS="bindata sqlite redis" make generate build` It's failing like this: ``` github.com/chaseadamsio/goorgeous Makefile:315: recipe for target 'gitea' failed make: *** [gitea] Error 1 ``` I can't tell whether `goorgeous` is where the failure happens, or if it's whatever comes after it. I realize old hardware compatibility isn't exactly something to shed tears over, but I'd be interested in any ideas if this seems fixable.
GiteaMirror commented 2025-11-02 05:23:10 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Aug 4, 2019):

Which OS?

@lunny commented on GitHub (Aug 4, 2019): Which OS?
GiteaMirror commented 2025-11-02 05:23:10 -06:00
Author
Owner
Copy Link

@lovett commented on GitHub (Aug 4, 2019):

Debian 9 stretch

@lovett commented on GitHub (Aug 4, 2019): Debian 9 stretch
GiteaMirror commented 2025-11-02 05:23:11 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Aug 5, 2019):

but we have released https://dl.gitea.io/gitea/1.9.0/gitea-1.9.0-linux-386

@lunny commented on GitHub (Aug 5, 2019): but we have released https://dl.gitea.io/gitea/1.9.0/gitea-1.9.0-linux-386
GiteaMirror commented 2025-11-02 05:23:11 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Aug 5, 2019):

I think that our i386 build may require sse2 x86 extensions. That your cpu does not have these implies it's very old... Are you sure it's powerful enough to run Gitea in general?

Ok, if you're certain you want to carry on. In order to help you figure out what is actually the problem we need the whole of the build log. One line is not going to cut it.

You definitely have standard Go not gcc-go right?

@zeripath commented on GitHub (Aug 5, 2019): I think that our i386 build may require sse2 x86 extensions. That your cpu does not have these implies it's very old... Are you sure it's powerful enough to run Gitea in general? Ok, if you're certain you want to carry on. In order to help you figure out what is actually the problem we need the whole of the build log. One line is not going to cut it. You definitely have standard Go not gcc-go right?
GiteaMirror commented 2025-11-02 05:23:11 -06:00
Author
Owner
Copy Link

@lovett commented on GitHub (Aug 6, 2019):

Yes, the hardware in question is very old. But I haven't had issues running Gitea with it prior to v1.9. My needs are modest.

As I mentioned earlier, it wouldn't be a surprise if not having sse2 was a dealbreaker here. I'm just mildly interested in whether there's an easy-ish fix that could side-step the issue, such as by disabling some module that otherwise isn't critical. But maybe that's not in the cards.

Here's the full output of the build command:
https://gist.github.com/lovett/c13953df47cb347d50311be0773eba46

Here's what go env reports:

$ go env
GOARCH="386"
GOBIN=""
GOCACHE="/home/lovett/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/tmp/gitea-test"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go-1.11"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.11/pkg/tool/linux_386"
GCCGO="gccgo"
GO386="387"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build606576234=/tmp/go-build -gno-record-gcc-switches"
@lovett commented on GitHub (Aug 6, 2019): Yes, the hardware in question is very old. But I haven't had issues running Gitea with it prior to v1.9. My needs are modest. As I mentioned earlier, it wouldn't be a surprise if not having sse2 was a dealbreaker here. I'm just mildly interested in whether there's an easy-ish fix that could side-step the issue, such as by disabling some module that otherwise isn't critical. But maybe that's not in the cards. Here's the full output of the build command: https://gist.github.com/lovett/c13953df47cb347d50311be0773eba46 Here's what `go env` reports: ``` $ go env GOARCH="386" GOBIN="" GOCACHE="/home/lovett/.cache/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="386" GOHOSTOS="linux" GOOS="linux" GOPATH="/tmp/gitea-test" GOPROXY="" GORACE="" GOROOT="/usr/lib/go-1.11" GOTMPDIR="" GOTOOLDIR="/usr/lib/go-1.11/pkg/tool/linux_386" GCCGO="gccgo" GO386="387" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build606576234=/tmp/go-build -gno-record-gcc-switches" ```
GiteaMirror commented 2025-11-02 05:23:11 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Aug 6, 2019):

I don't think it's goorgeous that's to blame for your problems with building:

go build golang_org/x/net/dns/dnsmessage: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/net/dns/dnsmessage.a: permission denied
go build golang_org/x/crypto/cryptobyte/asn1: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/cryptobyte/asn1.a: permission denied
go build golang_org/x/crypto/internal/chacha20: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/internal/chacha20.a: permission denied
go build golang_org/x/crypto/poly1305: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/poly1305.a: permission denied
go build golang_org/x/crypto/curve25519: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/curve25519.a: permission denied
gopkg.in/asn1-ber.v1
code.gitea.io/gitea/modules/process
go build golang_org/x/text/transform: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/text/transform.a: permission denied
go build golang_org/x/text/unicode/bidi: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/text/unicode/bidi.a: permission denied
go build golang_org/x/net/http2/hpack: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/net/http2/hpack.a: permission denied

I would look in to these errors first.

@zeripath commented on GitHub (Aug 6, 2019): I don't think it's goorgeous that's to blame for your problems with building: ``` go build golang_org/x/net/dns/dnsmessage: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/net/dns/dnsmessage.a: permission denied go build golang_org/x/crypto/cryptobyte/asn1: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/cryptobyte/asn1.a: permission denied go build golang_org/x/crypto/internal/chacha20: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/internal/chacha20.a: permission denied go build golang_org/x/crypto/poly1305: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/poly1305.a: permission denied go build golang_org/x/crypto/curve25519: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/crypto/curve25519.a: permission denied gopkg.in/asn1-ber.v1 code.gitea.io/gitea/modules/process go build golang_org/x/text/transform: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/text/transform.a: permission denied go build golang_org/x/text/unicode/bidi: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/text/unicode/bidi.a: permission denied go build golang_org/x/net/http2/hpack: open /usr/lib/go-1.11/pkg/linux_386/vendor/golang_org/x/net/http2/hpack.a: permission denied ``` I would look in to these errors first.
GiteaMirror commented 2025-11-02 05:23:12 -06:00
Author
Owner
Copy Link

@Sr4l commented on GitHub (Aug 6, 2019):

I also have problems building gitea 1.9 on Debian 10 Buster x64 with Go1.11 from repository. 1.8 on the other hand works fine.

web-git@server:~/go/src/code.gitea.io/gitea$ TAGS="bindata" make generate build
...SOME BUILD OUTPUT...
GO111MODULE=on go build -mod=vendor -i -v  -tags 'bindata' -ldflags '-s -w  -X "main.MakeVersion=GNU Make 4.2.1" -X "main.Version=1.9.0+10-gaea49d0b9" -X "main.Tags=bindata"' -o gitea
go build golang_org/x/net/dns/dnsmessage: open /usr/lib/go-1.11/pkg/linux_amd64/vendor/golang_org/x/net/dns/dnsmessage.a: permission denied
....SOME MORE PERMISSIONS DENIED...
go build golang_org/x/net/http2/hpack: open /usr/lib/go-1.11/pkg/linux_amd64/vendor/golang_org/x/net/http2/hpack.a: permission denied
go build golang_org/x/text/unicode/bidi: open /usr/lib/go-1.11/pkg/linux_amd64/vendor/golang_org/x/text/unicode/bidi.a: permission denied

I think it is related to this bug: https://github.com/golang/go/issues/27285
Removing -i from GOFLAGS helps, as mentioned by the bug report.

diff --git a/Makefile b/Makefile
index 796a0e3b5..532655052 100644
--- a/Makefile
+++ b/Makefile
@@ -22,7 +22,7 @@ BINDATA := modules/{options,public,templates}/bindata.go
 GOFILES := $(shell find . -name "*.go" -type f ! -path "./vendor/*" ! -path "*/bindata.go")
 GOFMT ?= gofmt -s
 
-GOFLAGS := -i -v
+GOFLAGS := -v
 EXTRA_GOFLAGS ?=
 
 MAKE_VERSION := $(shell make -v | head -n 1)
@Sr4l commented on GitHub (Aug 6, 2019): I also have problems building gitea 1.9 on Debian 10 Buster x64 with Go1.11 from repository. 1.8 on the other hand works fine. ``` bash web-git@server:~/go/src/code.gitea.io/gitea$ TAGS="bindata" make generate build ...SOME BUILD OUTPUT... GO111MODULE=on go build -mod=vendor -i -v -tags 'bindata' -ldflags '-s -w -X "main.MakeVersion=GNU Make 4.2.1" -X "main.Version=1.9.0+10-gaea49d0b9" -X "main.Tags=bindata"' -o gitea go build golang_org/x/net/dns/dnsmessage: open /usr/lib/go-1.11/pkg/linux_amd64/vendor/golang_org/x/net/dns/dnsmessage.a: permission denied ....SOME MORE PERMISSIONS DENIED... go build golang_org/x/net/http2/hpack: open /usr/lib/go-1.11/pkg/linux_amd64/vendor/golang_org/x/net/http2/hpack.a: permission denied go build golang_org/x/text/unicode/bidi: open /usr/lib/go-1.11/pkg/linux_amd64/vendor/golang_org/x/text/unicode/bidi.a: permission denied ``` I think it is related to this bug: https://github.com/golang/go/issues/27285 Removing **-i** from GOFLAGS helps, as mentioned by the bug report. ``` diff diff --git a/Makefile b/Makefile index 796a0e3b5..532655052 100644 --- a/Makefile +++ b/Makefile @@ -22,7 +22,7 @@ BINDATA := modules/{options,public,templates}/bindata.go GOFILES := $(shell find . -name "*.go" -type f ! -path "./vendor/*" ! -path "*/bindata.go") GOFMT ?= gofmt -s -GOFLAGS := -i -v +GOFLAGS := -v EXTRA_GOFLAGS ?= MAKE_VERSION := $(shell make -v | head -n 1) ```
GiteaMirror commented 2025-11-02 05:23:12 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Aug 7, 2019):

@Sr4l can you open a PR with this change ? Following https://github.com/golang/go/issues/27285#issuecomment-424382413 we should not use this flag anymore.

@sapk commented on GitHub (Aug 7, 2019): @Sr4l can you open a PR with this change ? Following https://github.com/golang/go/issues/27285#issuecomment-424382413 we should not use this flag anymore.
GiteaMirror commented 2025-11-02 05:23:12 -06:00
Author
Owner
Copy Link

@lovett commented on GitHub (Aug 7, 2019):

Dropping the -i flag resolved my issue as well. Thanks @Sr4l

@lovett commented on GitHub (Aug 7, 2019): Dropping the `-i` flag resolved my issue as well. Thanks @Sr4l
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3725
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?