Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // This test case makes sure that we don't run into LLVM's dreaded // "possible ODR violation" assertion when compiling with LTO + Debuginfo. // It covers cases that have traditionally been prone to cause this error. // If new cases emerge, add them to this file. // aux-build:debuginfo-lto-aux.rs // compile-flags: -C lto -g // no-prefer-dynamic extern crate debuginfo_lto_aux; fn some_fn(x: i32) -> i32 { x + 1 } fn main() { let i = 0; let _ = debuginfo_lto_aux::mk_struct_with_lt(&i); let _ = debuginfo_lto_aux::mk_regular_struct(1); let _ = debuginfo_lto_aux::take_fn(some_fn, 1); let _ = debuginfo_lto_aux::with_closure(22); let _ = debuginfo_lto_aux::generic_fn(0f32); } </ins>

Discussion:
I'm using msys2 x64 on Windows 7 and a fresh clone of Rust. cc
I've reproduced this issue on one more machine with Windows 8.1. I don't know why build bots don't catch it.
Probably a duplicate of It appears only with and the new error message is very similar to
Should actually be a dupe of which is closed by now. Can you check if this is fixed as well? Thanks!
Can't check now, the build with segfaults even before proceeding to tests.
This test still fails as of commit (at least when using MSVC):
The problem here seems to be that the namespaces recorded in the typenames and debuginfo don't always use the original create name, but "sometimes"(?) use the alias from . That way we get a duplicate definition for a type. One declared in namespace and one in .
Updated the title to reflect that this isn't specific to Windows.
This also affects
Somewhat unexpectedly, this also affects because this assertion fires when is finally passed correctly.
Just ran into this, so I can confirm this is still an issue
The problem is present also on OS X with recent update 10.11.4 and XCode 7.3. I have test the master branch . My configuration was: My test command was: The backtrace is the following:
Nominating so that compiler team addresses how to prioritize this.
triage: I-nominated T-compiler
(in particular, the fact that this is now visible on Windows and on later versions of Mac OS X is a sign that this problem is going to become a more significant problem for us than it has been in the past...)
cc
triage: P-medium
It's on my radar.
I've managed to replicate this bug in an Ubuntu virtual machine with llvm 3.8 from a fresh pull request. I built as per ituxbag above using and received the same error.
I'm seeing this on Arch Linux now as well.
Additionally, and fail the same way
Just hit this issue trying to compile cargo with and . BTW, I never enabled assertions during LLVM build - did the default change?
Still fails today--it would be really nice to see this fixed. I'd like use LTO for my embedded platform to get smaller binaries. (I already use --gc-sections, but LTO would be even better.)

On top of that, it looks like that, even if I set in profile overrides, I still get this failure because libcore and friends are built with -g.
FWIW it is possible to get this running with LTO -- we use LTO for . You just need to, as you mentioned, ensure libcore (and friends) are compiled without debug symbols for now. One simple way to do that for libcore is to depend on the crate which, behind the scenes, compiles libcore with whatever target and compiler arguments Cargo would otherwise use.
That crate seems quite outdated, but also not really enough. Currently I build the following for my target: libcore liblibcmini (a tiny implementation of OS-independent libc that I hacked up to make liballoc build) liballoc librustcunicode libcollections libpanicabort libpanicunwind (yes, I use unwinding; in fact that predates my use of Rust) It would be great if there was some elegant way to build all that with Cargo, but for now I don't see it... putting stuff on is onerous and especially so when tracking nightlies is desired, adding Rust as a submodule brings in a massive dependency into your project, and I've had issues with that before simply because the networks over here aren't very good and some build tools (coughcondacough) aren't very smart.
Take a look at the implementation of the rust-libcore crate. It's really just a that pulls in the version of libcore based on your (which is why it hasn't needed to be updated for a while) and then compiles it. You can do the same (perhaps by just modifying a local copy of the rust-libcore crate) for all of those since they are just in the Rust tarball. Note: obviously none of this solves the underlying bug, but just something to hold us non-compiler-folks while the professionals figure this out
That would work well if I didn't also have to use a fork of Rust (the upstream doesn't define the ABI or have the LLVM target initialization for my architecture). But thanks for telling anyway, I might be able to use this in some other form. The complete lack of caching and reliance on POSIX sh is still an issue...
I tried to reproduce it with the commands described in on nightly, but I couldn't. Can someone else also try it?

New to Rust, but this was halting my first ever compile of Redox. I read this: and changed on line 24 of to just so I could try out the OS. It shutup the error and let me compile, maybe this will help someone else who's stuck trying to run Redox. I have a Mac running OSX 10.12.2 and Xcode 8.2.1 with Rust Nightly