4.0.0-rc2 was just tagged from the branch at r294535.
There are still open relase blocking bugs and merge requests, so this
will not be the last release candidate, but we've had a lot of merges
since the last one, and I'd like to see what the testing looks like.
The test-release.sh script was updated to also include lld. Make sure
you're using the latest version of the script (ideally from the
branch, but the trunk version is identical), and if lld causes any
problems, pass the "-no-lld" flag.
Please build, test, and upload binaries to the sftp. Let me know what
comes up, and I'll publish your binaries plus source and docs when
they're ready.
Hi,
4.0.0-rc2 passed all tests on OpenMandriva x86_64, i586 and aarch64. armv7hl is still running (and will probably keep running for quite some time, slow board).
Ed may be able to elaborate on lldb+freebsd state of things.
All I can say is these tests did not exist in 3.9, so I wouldn't call
this a regression. (Well... technically, a similar test existed, but
it was run by a different test runner which I believe is not hooked up
to the command you are running).
We're on a similar state for libc++ / openmp / lld on ARM and AArch64.
libc++ works well on ARM and AArch64, but some of the tests fail
(always have), and I think Eric said it has to do with how we run them
or which ones should be disabled.
LLD works well on AArch64 but not yet on ARM (though there were no
test failures this time). OpenMP kind of works, but there are many
failures, which we won't look into this cycle.
Regardless of that state, we though it was a good idea to ship it as
an experimental status, so that people can try out and report bugs.
All the components above are included in both ARM and AArch64
releases.
Hans,
Do you think we should have a table of production vs. experimental
quality per target on the release notes, so that users know what to
expect? Or should we just let users know that when they report bugs?
Good question, we're not doing a very good job of documenting this.
And I'm not sure what would be the best way to do it.
A reasonable thing to do would be to put a note on the relaese
downloads page. But I'm not even sure what to put there. "OpenMP kind
of works on AArch64", what does that mean to a user?
It also comes back to what the nature of the release is. For me, it's
a periodic best-effort-stability snapshot of what we've got, which
packagers and other downstream folks build on.
A reasonable thing to do would be to put a note on the relaese
downloads page. But I'm not even sure what to put there. "OpenMP kind
of works on AArch64", what does that mean to a user?
The idea was to just separate in two classes: supported/not supported.
It also comes back to what the nature of the release is. For me, it's
a periodic best-effort-stability snapshot of what we've got, which
packagers and other downstream folks build on.
That's why I haven't bothered doing it, so far. What we can do is to
continue not doing it until someone really complains, than we try to
find a good solution.
I uploaded the following: