Bug 1547844 - Use ^uint32(0) instead of 0XFFFFFFFF in ipv4range.go for oc command so 32bit binaries will compile
Summary: Use ^uint32(0) instead of 0XFFFFFFFF in ipv4range.go for oc command so 32bit ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.9.0
Hardware: i386
OS: Windows
unspecified
medium
Target Milestone: ---
: 3.10.0
Assignee: Kenjiro Nakayama
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks: 1546634
TreeView+ depends on / blocked
 
Reported: 2018-02-22 05:14 UTC by Johnray Fuller
Modified: 2018-07-30 19:10 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-30 19:09:51 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1816 None None None 2018-07-30 19:10:18 UTC

Description Johnray Fuller 2018-02-22 05:14:15 UTC
Description of problem:

The binary for 32 bit Windows platform will not build do to the value for  fromCIDR() being set to 0XFFFFFFFF and hitting the upper bound for 32 bit non

Version-Release number of selected component (if applicable):

>= OCP 3.7

How reproducible:

Always

Steps to Reproduce:

# make all OS_BUILD_PLATFORMS=windows/386 WHAT=cmd/oc

Fails with an integer overflow error in ipv4range.go.

Actual results:

$ make all OS_BUILD_PLATFORMS=windows/386 WHAT=cmd/oc
hack/build-go.sh cmd/oc
++ Building go targets for windows/386: cmd/oc
# github.com/openshift/origin/pkg/oc/bootstrap/docker/dockerhelper
pkg/oc/bootstrap/docker/dockerhelper/ipv4range.go:106:22: constant 4294967295 overflows int
[ERROR] PID 24110: hack/lib/build/binaries.sh:235: `GOOS=${platform%/*} GOARCH=${platform##*/} go install -pkgdir "${pkgdir}/${platform}" -tags "${OS_GOFLAGS_TAGS-} ${!platform_gotags_envvar:-}" -ldflags="${local_ldflags}" "${goflags[@]:+${goflags[@]}}" "${nonstatics[@]}"` exited with status 2.
[INFO]         Stack Trace:
[INFO]           1: hack/lib/build/binaries.sh:235: `GOOS=${platform%/*} GOARCH=${platform##*/} go install -pkgdir "${pkgdir}/${platform}" -tags "${OS_GOFLAGS_TAGS-} ${!platform_gotags_envvar:-}" -ldflags="${local_ldflags}" "${goflags[@]:+${goflags[@]}}" "${nonstatics[@]}"`
[INFO]           2: hack/lib/build/binaries.sh:156: os::build::internal::build_binaries
[INFO]           3: hack/build-go.sh:25: os::build::build_binaries
[INFO]   Exiting with code 2.
[ERROR] PID 24039: hack/lib/build/binaries.sh:150: `local -a binaries=("$@")` exited with status 2.
[INFO]         Stack Trace:
[INFO]           1: hack/lib/build/binaries.sh:150: `local -a binaries=("$@")`
[INFO]           2: hack/build-go.sh:25: os::build::build_binaries
[INFO]   Exiting with code 2.
[ERROR] hack/build-go.sh exited with code 2 after 00h 04m 23s
make: *** [all] Error 2

Expected results:

Successful build.

Additional info:

I know that we do not build or release the 32 bit binaries of the oc command, but this change allows users to build the binaries themselves.

Pull Request upstream":

https://github.com/openshift/origin/pull/18653

Comment 1 Juan Vallejo 2018-02-23 00:29:26 UTC
Reassigning to Kenjiro as he already has a PR [1] to address this.

1. https://github.com/openshift/origin/pull/18653

Comment 4 Xingxing Xia 2018-03-07 09:48:15 UTC
Checked in latest Origin env (v3.10.0-alpha.0+c1befdd-95)
[root@ip-172-18-10-180 origin]# make all OS_BUILD_PLATFORMS=windows/386 WHAT=cmd/oc
hack/build-go.sh cmd/oc 
++ Building go targets for windows/386: cmd/oc
[INFO] hack/build-go.sh exited with code 0 after 00h 05m 59s

[root@ip-172-18-10-180 origin]# ls _output/local/bin/windows/386/
oc.exe

Copy oc.exe to Windows 10, oc commands can work.

PR is not in OCP yet. Because bug is reported against Product OCP, will verify bug when PR lands in OCP repo.

Comment 12 Xingxing Xia 2018-04-24 00:36:07 UTC
Per comment 6, bug is verified in 3.10. Thank you all

Comment 14 errata-xmlrpc 2018-07-30 19:09:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1816


Note You need to log in before you can comment on or make changes to this bug.