Should we continue to support FreeBSD?

[targos]

I'm opening this because at the moment, the update to V8 6.0 is blocked by FreeBSD 10 that cannot compile V8 because of a bug in Clang.
I opened an issue about that on May 9 and a suggestion was to upgrade Clang, so I opened another issue on the build repo for that on May 16.
Nothing really happened for about a month and then @kfarnung investigated a bit and found that we would need to update Clang to 3.8 to avoid the bug. @jbergstroem contacted the maintainers of the Node port for FreeBSD and it seems that upgrading Clang is not an option.
That leaves with having to find and apply a workaround to V8 for this bug. I already spent a few hours on this myself without success so far. The thing is, I don't think it's my responsibility (as the one who usually does the V8 upgrades) to fix platform issues.
I would like to question the presence of FreeBSD in the "Tier 2" support type because it seems to me that we don't have enough collaborators who care about it and who are ready to spend the time needed to make it green on our CI.

Refs: nodejs/node-v8#1
Refs: nodejs/build#723

/cc @nodejs/platform-freebsd @nodejs/ctc

[mcollina]

Great work @targos, we all know you tried hard on this. In the last few months I have heard only problems on how hard is to support FreeBSD 10.

We have two options: do not ship V8 6.0 in Node 8, and be at the risk of missing updates from the V8 team, or do not provide Node 8 in FreeBSD 10 for the time being.

Considering the overall community interests, I think we should go ahead and land V8 6.0, and ideally release it in Node 8.

@jbergstroem contacted the maintainers of the Node port for FreeBSD and it seems that upgrading Clang is not an option.

This means we can run builds with an upgraded Clang? If so, let's run builds and releases with the updated Clang. If there are binaries around, people can still use them, even if it couldn't be packaged.

[mcollina]

Great work @targos, we all know you tried hard on this. In the last few months I have heard only problems on how hard is to support FreeBSD 10.

We have two options: do not ship V8 6.0 in Node 8, and be at the risk of missing updates from the V8 team, or do not provide Node 8 in FreeBSD 10 for the time being.

Considering the overall community interests, I think we should go ahead and land V8 6.0, and ideally release it in Node 8.

@jbergstroem contacted the maintainers of the Node port for FreeBSD and it seems that upgrading Clang is not an option.

This means we can run builds with an upgraded Clang? If so, let's run builds and releases with the updated Clang. If there are binaries around, people can still use them, even if it couldn't be packaged.

[bnoordhuis]

We don't release binaries for freebsd. If clang 3.8 fixes the ICE, then upgrading is what needs to happen.

Shouldn't be a problem for our CI. If it's a problem for the ports packagers, well, the good news is it's their problem, not ours.

[bnoordhuis]

We don't release binaries for freebsd. If clang 3.8 fixes the ICE, then upgrading is what needs to happen.

Shouldn't be a problem for our CI. If it's a problem for the ports packagers, well, the good news is it's their problem, not ours.

[targos]

If clang 3.8 fixes the ICE, then upgrading is what needs to happen.

Then we need to change the requirements in https://github.com/nodejs/node/blob/master/BUILDING.md#unix

@nodejs/v8 is there version range of Clang that is officially supported by V8 or it's just the latest?

Clang is what's blocking us to ship V8 6.0, but it's not the only problem we have with FreeBSD. Right now Canary is broken on FreeBSD 10 and 11 and I don't know who I can ask to look into the issue and submit a patch upstream.
I think that for each platform that we support in Tier 1 and Tier 2, we should have active collaborators who are able to fix issues quickly when they arise. It works very well with SmartOS and PPC for example.

[targos]

If clang 3.8 fixes the ICE, then upgrading is what needs to happen.

Then we need to change the requirements in https://github.com/nodejs/node/blob/master/BUILDING.md#unix

@nodejs/v8 is there version range of Clang that is officially supported by V8 or it's just the latest?

Clang is what's blocking us to ship V8 6.0, but it's not the only problem we have with FreeBSD. Right now Canary is broken on FreeBSD 10 and 11 and I don't know who I can ask to look into the issue and submit a patch upstream.
I think that for each platform that we support in Tier 1 and Tier 2, we should have active collaborators who are able to fix issues quickly when they arise. It works very well with SmartOS and PPC for example.

[bnoordhuis]

is there version range of Clang that is officially supported by V8 or it's just the latest?

I don't think the V8 people make any guarantee except google's clang fork (and maybe the one version of gcc that's tested in their CI.)

[bnoordhuis]

is there version range of Clang that is officially supported by V8 or it's just the latest?

I don't think the V8 people make any guarantee except google's clang fork (and maybe the one version of gcc that's tested in their CI.)

[jbergstroem]

I'm ok with updating clang; the maintainers are both responsive and helpful in patching upstream. They just don't act as much on non-releases/pre-releases.

[jbergstroem]

I'm ok with updating clang; the maintainers are both responsive and helpful in patching upstream. They just don't act as much on non-releases/pre-releases.

[mcollina]

@jbergstroem let's update clang so we can move forward with landing V8 6.0.

[mcollina]

@jbergstroem let's update clang so we can move forward with landing V8 6.0.

[jbergstroem]

@mcollina sure.

[jbergstroem]

@mcollina sure.

[emaste]

I'm not sure why it would be a problem to use a newer Clang to build node packages in FreeBSD 10 - we have many packages that depend on having a newer Clang. (And we can't update Clang in 10.x, because we want 10.x to be buildable from older FreeBSD releases which do not include a compiler that can compile C++11 software). That said, I'm not involved in packaging node on FreeBSD so I could be missing something.

One of my goals is to support upstream software projects in running on FreeBSD though so feel free to CC me on issues and I will try to find someone to help.

[emaste]

I'm not sure why it would be a problem to use a newer Clang to build node packages in FreeBSD 10 - we have many packages that depend on having a newer Clang. (And we can't update Clang in 10.x, because we want 10.x to be buildable from older FreeBSD releases which do not include a compiler that can compile C++11 software). That said, I'm not involved in packaging node on FreeBSD so I could be missing something.

One of my goals is to support upstream software projects in running on FreeBSD though so feel free to CC me on issues and I will try to find someone to help.

[nomadlogic]

@targos is there a bug report regarding Canary as per:
"Clang is what's blocking us to ship V8 6.0, but it's not the only problem we have with FreeBSD. Right now Canary is broken on FreeBSD 10 and 11 and I don't know who I can ask to look into the issue and submit a patch upstream."

I'd like to take a look at the issue and see if I can help triage and see what I can do to help fix it.

As @emaste mentions - I'd also be keen to understand why having an updated Clang installed via ports/pkgs as a requirement would be an issue. Is there a thead or PR I can take a look at?

[nomadlogic]

@targos is there a bug report regarding Canary as per:
"Clang is what's blocking us to ship V8 6.0, but it's not the only problem we have with FreeBSD. Right now Canary is broken on FreeBSD 10 and 11 and I don't know who I can ask to look into the issue and submit a patch upstream."

I'd like to take a look at the issue and see if I can help triage and see what I can do to help fix it.

As @emaste mentions - I'd also be keen to understand why having an updated Clang installed via ports/pkgs as a requirement would be an issue. Is there a thead or PR I can take a look at?

[DimitryAndric]

It would be nice if somebody could retrieve the reproduction files that were reported in the original crash report, e.g:

Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/wasm-module-87662f.cpp
c++: note: diagnostic msg: /tmp/wasm-module-87662f.sh

But most likely those artifacts are long gone now? Is there any other good way to reproduce?

[DimitryAndric]

It would be nice if somebody could retrieve the reproduction files that were reported in the original crash report, e.g:

Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/wasm-module-87662f.cpp
c++: note: diagnostic msg: /tmp/wasm-module-87662f.sh

But most likely those artifacts are long gone now? Is there any other good way to reproduce?

[mhdawson]

I agree with @targos that the real question is not necessarily how we fix this specific issue (upgrade compiler or something else) but making sure we have enough collaborator/contributors lined up who will help to investigate/resolve issues on FreeBSD. While it would be a shame to not have Node.js build on FreeBSD unless we can identify who is going to jump on those issues it is something we have to consider.

Should we be making a public call for somebody to step up with the suggestion we may have to drop it otherwise ?

[mhdawson]

I agree with @targos that the real question is not necessarily how we fix this specific issue (upgrade compiler or something else) but making sure we have enough collaborator/contributors lined up who will help to investigate/resolve issues on FreeBSD. While it would be a shame to not have Node.js build on FreeBSD unless we can identify who is going to jump on those issues it is something we have to consider.

Should we be making a public call for somebody to step up with the suggestion we may have to drop it otherwise ?

[addaleax]

I have the impression that, as long as the individuals who are volunteering here to support Node.js on FreeBSD as an effort (anybody who wants to join @nodejs/platform-freebsd, please explicitly raise your hands :) ) are committed to doing so, there is no real problem.

[addaleax]

I have the impression that, as long as the individuals who are volunteering here to support Node.js on FreeBSD as an effort (anybody who wants to join @nodejs/platform-freebsd, please explicitly raise your hands :) ) are committed to doing so, there is no real problem.

[refack]

Should we be making a public call for somebody to step up with the suggestion we may have to drop it otherwise ?

Since this thread got fragmented a bit... AFAICT in #14499 (comment) @emaste and @bradleythughes have officially volunteered.

@targos and @gibfahn could consider closing their respective threads when they come back from vacation.

[refack]

Should we be making a public call for somebody to step up with the suggestion we may have to drop it otherwise ?

Since this thread got fragmented a bit... AFAICT in #14499 (comment) @emaste and @bradleythughes have officially volunteered.

@targos and @gibfahn could consider closing their respective threads when they come back from vacation.

[targos]

@emaste is now in the platform-freebsd team and I invited @bradleythughes. Thank you to both of you for stepping up!
I think we can close this issue for now.

[targos]

@emaste is now in the platform-freebsd team and I invited @bradleythughes. Thank you to both of you for stepping up!
I think we can close this issue for now.