Bug 1302704 - part 5 - harmonize gkrust_gtest's profile.release with gkrust's; r=chmanchester
authorNathan Froyd <froydnj@mozilla.com>
Thu, 23 Feb 2017 10:35:07 -0500
changeset 373625 7cbbf867604cadcc1f083848cd42222997aad251
parent 373624 95b0a622699271828ef3bcb644837be4a5bf0d7d
child 373626 e71b6d1907a868c5aa67913755de36dc151a8cb3
push id10863
push userjlorenzo@mozilla.com
push dateMon, 06 Mar 2017 23:02:23 +0000
treeherdermozilla-aurora@0931190cd725 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerschmanchester
bugs1302704
milestone54.0a1
Bug 1302704 - part 5 - harmonize gkrust_gtest's profile.release with gkrust's; r=chmanchester The comment here is a relic from bygone days when we tried sticking gkrust and gkrust-gtest into the same library at link time. Making gkrust and gkrust-gtest's profile.release settings identical also means that Cargo considers build artifacts from one suitable for the other, which is extremely desirable with our new shared CARGO_TARGET_DIR setup.
toolkit/library/gtest/rust/Cargo.toml
--- a/toolkit/library/gtest/rust/Cargo.toml
+++ b/toolkit/library/gtest/rust/Cargo.toml
@@ -34,16 +34,11 @@ lto = false
 debug-assertions = true
 codegen-units = 1
 panic = "abort"
 
 [profile.release]
 opt-level = 2
 debug = true
 rpath = false
-# This would normally be 'true' for release configurations, but using LTO on
-# rul-gtest causes link failures due to symbols also being found in libxul's
-# librul.a.  But LTO'ing things here is not crucial and not LTO'ing things
-# enables us to link libxul-gtest, so we leave it turned off.
-lto = false
+lto = true
 debug-assertions = false
-codegen-units = 1
 panic = "abort"