https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.52.0 2021-03-01T22:35:35+00:00 2021-03-01T22:35:35+00:00 Nikita Popov nikita.ppv@gmail.com 2021-02-28T17:16:39+00:00 urn:sha1:34352d441a6430b5b85029efc0569a88999b2ac8 When cross-compiling to solaris/illumos targets, set CMAKE_SYSTEM_NAME to SunOS. 2021-02-08T07:48:58+00:00 Tri Vo trong@google.com 2021-01-23T02:32:38+00:00 urn:sha1:c7d9bffe76477a2f79c468b07e5eaf82525eea99 2021-01-30T16:44:49+00:00 Nikita Popov nikita.ppv@gmail.com 2021-01-30T16:44:49+00:00 urn:sha1:8c7611caf0cfd251c7737fdf6fb9adb6bb29802a This reverts commit cb6787ae82d388045cdf6b5dc73787d828d91feb, reversing changes made to 0248c6f178ab3a4d2ec702b7d418ff8375ab0515. 2021-01-28T22:01:11+00:00 Nikita Popov nikita.ppv@gmail.com 2021-01-28T22:01:11+00:00 urn:sha1:a84ff2b6d4b6f1e5a315cc043bb8e2b730f254f4 This avoids a conflict if llvm.thin-lto=true is combined with an explicit llvm.use-linker=lld. 2021-01-28T20:07:34+00:00 Nikita Popov nikita.ppv@gmail.com 2021-01-27T20:27:46+00:00 urn:sha1:e066deae088dfeef66c414c181925b28b9a25511 LLVM 12 no longer builds with Python 2, so install Python 3 in preparatin. However, Clang 10 does not build with Python 3, so we need update to Clang 11 as well, which supports both. Unfortunately, doing so results in errors while linking the libLLVM.so into other binaries: > __morestack: invalid needed version 2 This is fixed by using LLD instead. Possibly this is due to a binutils linker bug, but updating to the latest binutils version does not fix it. 2021-01-16T03:07:38+00:00 Joshua Nelson jyn514@gmail.com 2021-01-12T01:28:17+00:00 urn:sha1:67660704229ba03d9b305bd938cd1f8f0bf65d11 - Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked statically - Add `link-type.txt` so bootstrap knows whether llvm was linked statically or dynamically - Don't assume CI LLVM is linked dynamically in `bootstrap::config` - Fall back to dynamic linking if `link-type.txt` doesn't exist - Fix existing bug that split the output of `llvm-config` on lines, not spaces - Enable building LLVM tests This works around the following llvm bug: ``` llvm-config: error: component libraries and shared library llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles" ``` I'm not sure why llvm-config thinks these are required, but to avoid the error, this builds them anyway. - Temporarily set windows as the try builder. This should be reverted before merging. - Bump version of `download-ci-llvm-stamp` `src/llvm-project` hasn't changed, but the generated tarball has. - Only special case MacOS when dynamic linking. Static linking works fine. - Store `link-type.txt` to the top-level of the tarball This allows writing the link type unconditionally. Previously, bootstrap had to keep track of whether the file IO *would* succeed (it would fail if `lib/` didn't exist), which was prone to bugs. - Make `link-type.txt` required Anyone downloading this from CI should be using a version of bootstrap that matches the version of the uploaded artifacts. So a missing link-type indicates a bug in x.py. 2020-12-10T04:53:53+00:00 Corey Farwell coreyf@rwell.org 2020-12-10T04:53:53+00:00 urn:sha1:5940c193159a40fc9ebecc0de1482ba3d0a7a2dc 2020-11-12T13:39:47+00:00 DevJPM jean-pierre.muench@web.de 2020-11-07T21:53:44+00:00 urn:sha1:6830f1c6e25bb5a49782d71698878ed9ed97523c 2020-10-30T10:23:02+00:00 Joseph Rafael Ferrer rafael2x0@gmail.com 2020-10-30T10:19:56+00:00 urn:sha1:301bb123f424954cd3faee11bbbfb0605e5ae0e8 2020-10-16T07:32:41+00:00 Niels Sascha Reedijk niels.reedijk@gmail.com 2020-09-19T08:17:53+00:00 urn:sha1:7b652d341e9a476658af8a9186972ce73ec38c3c This resolves issues where the cross-build of LLVM fails because it tries to link to the host's system libraries instead of the target's system libraries.