Date: Thu, 18 Dec 2014 07:47:31 -0700 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@freebsd.org> Cc: FreeBSD ARM <freebsd-arm@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org>, portmgr@FreeBSD.org, FreeBSD ports <freebsd-ports@freebsd.org>, FreeBSD toolchain <freebsd-toolchain@freebsd.org> Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Message-ID: <EF805BD1-34FA-433A-A149-9498A9B3A159@bsdimp.com> In-Reply-To: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is excellent news Dimitry! > On Dec 16, 2014, at 12:36 PM, Dimitry Andric <dim@freebsd.org> wrote: >=20 > On 28 Nov 2014, at 22:03, Dimitry Andric <dim@FreeBSD.org> wrote: >>=20 >> We're working on updating llvm, clang and lldb to 3.5.0 in head. = This >> is quite a big update again, and any help with testing is = appreciated. >>=20 >> To try this out, ensure you have good backups or snapshots, then = build >> world and kernel from the projects/clang350-import branch [1]. = Please >> use a Subversion mirror [2], if you are able to. >=20 > Here are some updates about the status of the 3.5.0 import. >=20 > * i386 and amd64 have been tested through make universe, and = everything > should compile and run. > * Little-endian ARM builds should now compile and run, thanks to = Andrew > Turner for putting in lots of work. > * Big-endian ARM is apparently supposed to work, but I'm not sure if > Andrew managed to test it on real hardware. I know Andrew doesn=E2=80=99t have the right arm gear to do this test, = and emulation environments that run FreeBSD have had poor big-endian support for arm. > * PowerPC64 should mostly work, thanks to Justin Hibbits. > * PowerPC32 might start working soon; it really needs some backporting > of fixes to clang 3.4.1, which is now in head, so there is an easier > upgrade path for PowerPC users. > * Sparc64 still does not work, and I don't see any quick solutions to = it > for now. It should probably stay with gcc. > * Mips will only have a chance with the upcoming clang 3.6.0, but that > is way too late for this import. It will probably require external > toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. > * Another ports exp-run was done [3], after fixing the problem with > lang/gcc, which lead to many skipped dependent ports. > * The second exp-run had much better results: the failure with the > highest number of dependencies is devel/mingw32-gcc, but this seems > to be due to a problem with makeinfo, not clang. The next highest on > the list is java/openjdk6, for which ports r374780 [4] was very > recently committed. Will users of our stable branch have code similar to the code that = caused problems? One warning flag about your upgrade to the stable branch would be if there=E2=80=99s a significant number of user-written = programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there=E2=80=99s a good chance we won=E2=80=99t find them until users hit = them and start to complain (by which point it is likely too late). Could you post a = summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. > I would really like to merge this branch to head in about a week, > pending portmgr approvall; I don't expect the base system (outside of > llvm/clang) to need any further updates. I think there=E2=80=99s good reason to do this, but we should chat about = the build issues below before doing it. They are minor, but an important detail. I=E2=80=99ll see if I can find a few minutes to pull the branch = and send patches. > Lastly, to clear things up about the requirements for this branch (and > thus for head, in a while); to build it, you need to have: > * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) > * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >=20 > So from any earlier standard 10.x or 11.x installation, you should be > good, unless you explicitly disabled clang or libc++. In that case, > you must build and install both of those first. This is true only on i386, amd64, and arm hosts. Given that some people do try to do weird things, tightening up how you present this will get = the word out a little better. > On a 9.x installation, you will have clang by default, but not libc++, > so libc++ should be built and installed first, before attempting to > build the clang350-import branch. Can you make sure that the UPDATING entry you are writing for this contains explicit instructions. > On 8.x an earlier, you need to upgrade to at least 9.x first, follow > the previous instruction. We should remove building on 8 support then, unless there external toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc). > As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while > (roughly a month), but this will cause upgrades from 9.x to 10.x to > start requiring the build of libc++, as described above. I don't = think > we can merge clang 3.5.x to 9.x, unless clang becomes the default > compiler there (but that is very unlikely). Let=E2=80=99s see how it goes, and what the upgrade issues wind up being before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers on = stable branches traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly identical to prior releases than gcc was, it might not have the same = issues associated with it. Warner --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkukEAAoJEGwc0Sh9sBEAT0kP/Rnez5JSvAwYw80kxMc/Ui1P rvW0Nq7D3sMYxXHY13Frt0+yT/7JEZpXMRGFGHijwaKd/iSgUT2W04BQAYHkjWWj Z2cq/mFLrKtcS8puBpDGC9hGkZ6jeB06k6N82mu+HrbrMtNxb7Rl9MAeaPyZl0vb dmKVFmSDSnlNCSSE6sJygmexT4JKcP+2Bv8U/C4htCsKwnYzbroUJVhmhNwm6NHp Tgloml0B3IVdd3rY91uW6Ie1He1px96uoFnFS7IeHWsC2CkVKrpdOwoLXJdk8ofr /uyKvOCng7pmGmoNVE6/h0RdPGGatjHwdHgF2V1in4I2XNWmavMq8Js3+ipPAB0t ox4TMQqGWnOIAsGJiyAboPbrC4gTj3DpTVJp4SyROYMWMXtp8w26fOktzwErmHEq ghxR8GO8ypq5lhpURuzyprkn4rp++PHeLN5soDmFYjx8k39FXB8iWkrhFjiyaNh4 kaa1GWXTxuaDOMiDRLjgluo7LstAn5jUir0HX/CnPgycEFw5yCxEia7dTqHj0Jmx uGdx8a+ZnSptbuSjfytT0BH9TLRj2wYdGmwGNA12KrgYOuBTCZqEaOpdYvE0KN2W 4tFdAfr13vUzcUk0W6bD1uVFUn2myKvy7gxPD7C4+NyJ5ZUTLHKiwyeFn3O7KzeL QDFb8Gg5HEyaoGI9gSpf =k3ZX -----END PGP SIGNATURE----- --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EF805BD1-34FA-433A-A149-9498A9B3A159>