Page MenuHomeFreeBSD

lang/go: flavorize; add -nosse2 flavor for older i386 CPUs lacking SSE2 support
AbandonedPublic

Authored by mat on Aug 18 2018, 2:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 17 2024, 10:27 AM
Unknown Object (File)
Dec 22 2023, 11:40 PM
Unknown Object (File)
Nov 25 2023, 5:32 AM
Unknown Object (File)
Nov 23 2023, 10:39 AM
Unknown Object (File)
Nov 8 2023, 6:36 AM
Unknown Object (File)
Nov 6 2023, 3:33 PM
Unknown Object (File)
Oct 21 2023, 6:04 PM
Unknown Object (File)
Oct 18 2023, 9:48 PM

Details

Summary

PR: 230731

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 18967
Build 18607: arc lint + arc unit

Event Timeline

lang/go: flavorize; add -nosse2 flavor for older i386 CPUs lacking SSE2 support

dmgk retitled this revision from Flavorize; add -nosse2 flavor for older CPUs lacking SSE2 support to lang/go: flavorize; add -nosse2 flavor for older i386 CPUs lacking SSE2 support.Aug 18 2018, 5:08 PM

I'm not sure if I got the problem lead to this option/flavor-izing completely.
But I had an issue with SSE4.2-ops on MySQL,
with suggestion of people,added "compiler:c++14-lang" fixed it naturally because it added "correct" dependency/flags to port's build-env...

Well, on this port you have --nosse2 option already on build (and honestly I can't say exact difference of SSE4.2 and SSE2 ๐Ÿ˜… ), but maybe you can compare these two approaches and use better one :)
hopefully it helped a little ๐Ÿ˜„

The issue with SSE2 here is not related to C compiler flags or build environment. lang/go is self-hosting and doesn't use C compiler during build.

The problem is that Go by default uses SSE2 for floating point operations and because of that, prebuilt binary package doesn't run on older CPUs that do not have SSE2 instructions. Currently, lang/go port has a knob to disable SSE2 and turning this knob ON does produce runnable package. The idea behind this patch is to add a distinct -nosse2 flavor so we can have two prebuilt binary packages - one (default flavor) is with SSE2 instructions enabled and another (nosse2 flavor) is with SSE2 instructions disabled, intended to be used with older CPUs.

The flavor does not make much sense.

First because it is only needed for i386 processors before pentium 4, so it only concerns on i386 architecture, so having a flavor on all other archs is bogus.
Second, do you have real example of people actually running Go on machines from last century?

In D16789#357744, @mat wrote:

The flavor does not make much sense.

First because it is only needed for i386 processors before pentium 4, so it only concerns on i386 architecture, so having a flavor on all other archs is bogus.

I was also wondering if it would be possible to somehow declare this flavor arch-specific (i386-only).

Second, do you have real example of people actually running Go on machines from last century?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230731

In D16789#357745, @dg_syrec.org wrote:
In D16789#357744, @mat wrote:

The flavor does not make much sense.

First because it is only needed for i386 processors before pentium 4, so it only concerns on i386 architecture, so having a flavor on all other archs is bogus.

I was also wondering if it would be possible to somehow declare this flavor arch-specific (i386-only).

I think you could get away with doing something like this:

FLAVORS= ${FLAVORS_${ARCH}}
FLAVORS_i386= blah
FLAVOR?= ${FLAVORS:[1]}

But I am still not sure this is a good idea to begin with.

Second, do you have real example of people actually running Go on machines from last century?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230731

That is completely insane.

But for this one case, I think an option is enough. Because in any way, you are not going to be able to build or run anything with the ports tree because the built in go is lang/go and it will have SS2 enabled, so nothing will be built with the nosse2 flavor, it will only be possible to install it, and that's it.

Scope flavors to i386 arch.

The more I think about it, the more it is going to be useless because of what I just said. You are going to be able to install go-nosse2, but you won't be able to build anything with it, as it is not the default flavor.

Or, you're going to need to add flavors to all the ports depending on go, and that, only for one person.

I really think the option is the best way to go.

After further discussion, port option seems like a best solution. Closing, sorry for the noise.

mat abandoned this revision.
mat added a reviewer: dmgk.
In D16789#357757, @mat wrote:
In D16789#357745, @dg_syrec.org wrote:
In D16789#357744, @mat wrote:

The flavor does not make much sense.

First because it is only needed for i386 processors before pentium 4, so it only concerns on i386 architecture, so having a flavor on all other archs is bogus.

I was also wondering if it would be possible to somehow declare this flavor arch-specific (i386-only).

I think you could get away with doing something like this:

FLAVORS= ${FLAVORS_${ARCH}}
FLAVORS_i386= blah
FLAVOR?= ${FLAVORS:[1]}

But I am still not sure this is a good idea to begin with.

Second, do you have real example of people actually running Go on machines from last century?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230731

That is completely insane.

Care to elaborate why do you call my PR of real-world example "insane"?

But for this one case, I think an option is enough. Because in any way, you are not going to be able to build or run anything with the ports tree because the built in go is lang/go and it will have SS2 enabled, so nothing will be built with the nosse2 flavor, it will only be possible to install it, and that's it.

That's not true. Once nosse2-flavor of golang is installed, any golang port will build without SSE2, provided same named binaries of golang.