PR: 230731
Details
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 18937 Build 18583: arc lint + arc unit
Event Timeline
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?
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?
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?
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.
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.
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.