Skip to content

Build failure using source tar for 1.27.1 #52227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bryteise opened this issue Jul 10, 2018 · 15 comments
Closed

Build failure using source tar for 1.27.1 #52227

bryteise opened this issue Jul 10, 2018 · 15 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@bryteise
Copy link

Attempting to build 1.27.1 from https://static.rust-lang.org/dist/rustc-1.27.1-src.tar.gz gives the following error:

   Compiling proc-macro2 v0.3.6
error[E0463]: can't find crate for `proc_macro`
  --> vendor/proc-macro2/src/lib.rs:31:1
   |
31 | extern crate proc_macro;
   | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
@Mark-Simulacrum Mark-Simulacrum added I-nominated T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Jul 10, 2018
@Mark-Simulacrum
Copy link
Member

cc @alexcrichton

@alexcrichton
Copy link
Member

@bryteise can you share steps of how to reproduce this? What configure arguments did you use? What system are you on? Do you have more logs we can inspect?

@bryteise
Copy link
Author

Sure, I should add I see this when trying to rebuild 1.27.0 using the 1.27.0 compiler built with the same configuration flags (both using cargo 0.28.0).

The flags are

    --build=x86_64-unknown-linux-gnu \                                                                                               
    --host=x86_64-unknown-linux-gnu \                                                                                                
    --target=x86_64-unknown-linux-gnu \                                                                                              
    --disable-option-checking \                                                                                                      
    --libdir=/usr/lib \                                                                                                              
    --enable-local-rust \                                                                                                            
    --local-rust-root=/usr \                                                                                                         
    --llvm-root=/usr \                                                                                                               
    --disable-codegen-tests \                                                                                                        
    --enable-llvm-link-shared \                                                                                                      
    --disable-jemalloc \                                                                                                             
    --disable-rpath \                                                                                                                
    --enable-debuginfo \                                                                                                             
    --enable-vendor \                                                                                                                
    --release-channel=stable 

I am running on Clear Linux. Logs for 1.27.0 and 1.27.1 attached.
1.27.0-log.txt
1.27.1-log.txt

We are also carrying a patch that fixes a different build problem.

@bryteise
Copy link
Author

Oh I'm just dumb and was missing the other patch Fedora is carrying to avoid conflicts with the stage0 compiler bits. Nevermind X(.

@bryteise
Copy link
Author

So I thought this was related to #48319 but looking at the config.toml full-bootstrap is not enabled.
Full config attached.

1.27.1-config.toml.txt

And I added verbose logging and the added verbosity gave me the compiler command used:

     Running `/usr/bin/rustc --crate-name proc_macro2 vendor/proc-macro2/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=7ff6799d5f803168 -C extra-filename=-7ff6799d5f803168 --out-dir /builddir/build/BUILD/rustc-1.27.1-src/build/bootstrap/debug/deps -L dependency=/builddir/build/BUILD/rustc-1.27.1-src/build/bootstrap/debug/deps --extern unicode_xid=/builddir/build/BUILD/rustc-1.27.1-src/build/bootstrap/debug/deps/libunicode_xid-df8fd254b50536c5.rlib --cap-lints allow -Cdebuginfo=2`                                                                
error[E0463]: can't find crate for `proc_macro`
  --> vendor/proc-macro2/src/lib.rs:31:1
   |
31 | extern crate proc_macro;
   | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

@bryteise bryteise reopened this Jul 11, 2018
@bryteise
Copy link
Author

The problem seems to be the system proc_macro crate isn't able to load, I note the strace shows the usual 1.27 dance of:

lstat("/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so", {st_mode=S_IFREG|0755, st_size=620672, ...}) = 0
stat("/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so", {st_mode=S_IFREG|0755, st_size=620672, ...}) = 0
openat(AT_FDCWD, "/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so", O_RDONLY|O_CLOEXEC) = 5</usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>
fstat(5</usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>, {st_mode=S_IFREG|0755, st_size=620672, ...}) = 0
mmap(NULL, 620672, PROT_READ, MAP_PRIVATE, 5</usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>, 0) = 0x7ff59e1a2000
close(5</usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>) = 0

But then does a

munmap(0x7ff59e1a2000, 620672)          = 0
write(2</dev/pts/1>, "\33[0m\33[1m\33[38;5;9merror[E0463]\33[0"..., 384error[E0463]: can't find crate for `proc_macro`

for a simple little

$ echo 'extern crate proc_macro;
fn main()
{
 println!("hi");
}' > test.rs
$ strace rustc test.rs

The proc_macro .so library seems to have normal looking content under readelf -s and rustc --verbose doesn't give any new information. The binary content including the proc_macro lib can be found here but I'm not sure what to look through next. We do configure the libdir for /usr/lib and then mv the libs and rustlib over to /usr/lib64 after the build though if I move them back over to /usr/lib I get a linker error:

$ rustc -L/usr/lib -L/usr/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends -L/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib test.rs       
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "tst.tst0.rcgu.o" "tst.tst1.rcgu.o" "tst.tst2.rcgu.o" "tst.tst3.rcgu.o" "tst.tst4.rcgu.o" "tst.tst5.rcgu.o" "-o" "tst" "tst.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/usr/lib" "-L" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends" "-L" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/usr/lib" "-l" "proc_macro-9d1587d1f15e5104" "-L" "/usr/lib" "-l" "syntax-d49885b2305c3b00" "-L" "/usr/lib" "-l" "rustc_target-f838887cabe12b27" "-L" "/usr/lib" "-l" "rustc_errors-ed2290d1f4b4e6e1" "-L" "/usr/lib" "-l" "syntax_pos-b4179acb4fee88ad" "-L" "/usr/lib" "-l" "rustc_data_structures-bc75c4de2fe1f78a" "-L" "/usr/lib" "-l" "rustc_cratesio_shim-8f901d3571cc3ce2" "-L" "/usr/lib" "-l" "serialize-09bb3c8d6c3bd878" "-Wl,--start-group" "-L" "/usr/lib" "-l" "std-682c743c97115687" "-Wl,--end-group" "-Wl,-Bstatic" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-09d897d3a634a28f.rlib" "-Wl,-Bdynamic" "-l" "util" "-l" "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-l" "util"
  = note: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-682c743c97115687.so: undefined reference to `rust_metadata_std_e9e557cbe6ff8dd919e08d2804b88683'
          collect2: error: ld returned 1 exit status

Which looks gets passed the proc_macro portion going off of strace:

stat("/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so", {st_mode=S_IFREG|0755, st_size=620672, ...})
= 0
openat(AT_FDCWD, "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so", O_RDONLY|O_CLOEXEC) = 5</usr/lib/
rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>
fstat(5</usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>, {st_mode=S_IFREG|0755, st_size=620672, ...}
) = 0
mmap(NULL, 620672, PROT_READ, MAP_PRIVATE, 5</usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>, 0) = 0
x7f6163a5a000
close(5</usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-9d1587d1f15e5104.so>) = 0
munmap(0x7f6163a5a000, 620672)          = 0
stat("/usr/lib/libproc_macro-9d1587d1f15e5104.so", {st_mode=S_IFREG|0644, st_size=885080, ...}) = 0
openat(AT_FDCWD, "/usr/lib/libproc_macro-9d1587d1f15e5104.so", O_RDONLY|O_CLOEXEC) = 5</usr/lib/libproc_macro-9d1587d1f15e5104.so>
fstat(5</usr/lib/libproc_macro-9d1587d1f15e5104.so>, {st_mode=S_IFREG|0644, st_size=885080, ...}) = 0
mmap(NULL, 885080, PROT_READ, MAP_PRIVATE, 5</usr/lib/libproc_macro-9d1587d1f15e5104.so>, 0) = 0x7f6163a19000
close(5</usr/lib/libproc_macro-9d1587d1f15e5104.so>) = 0
brk(0x55b2f57ea000)                     = 0x55b2f57ea000
brk(0x55b2f584a000)                     = 0x55b2f584a000
munmap(0x7f6163a19000, 885080)          = 0

Though this looks a bit different from successful compilation still from a different system. I'm mostly just confused at this point.

@alexcrichton
Copy link
Member

It looks like it's failing very early in the build, when it's building the build system. That probably means that something may not be quite right about your bootstrap compiler? If you let the bootstrap download its own compiler does the help the situation?

@bryteise
Copy link
Author

Yes, sorry I should have added more background. This is using a bootstrap compiler that was built using the prebuilt rustc binary as the original bootstrap compiler (using the same configure flags). This compiler seems to be unable to find the correct libdir for the moved libraries even after the ldconfig cache has been built and if the libraries are not moved has the linker error I mentioned above (libstd-682c743c97115687.so: undefined reference to `rust_metadata_std_e9e557cbe6ff8dd919e08d2804b88683').

@alexcrichton
Copy link
Member

It looks like the bootstrap compiler can't find its own set of target libraries though? If it can find std but not proc_macro that's suspicious!

@bryteise
Copy link
Author

Exactly! I'm curious why the strace log above shows it finding the library at least at some point during the compilation but then printing out it can't find the proc_macro crate when I have the libraries moved to /usr/lib64 from /usr/lib. I could live with just creating symlinks to /usr/lib64 for everything but that doesn't work either (based on the linker error if I have the libraries in /usr/lib).

@alexcrichton
Copy link
Member

I'm not sure myself :(

It doesn't sound like this is a regression, though, so I'm going to remove the tag.

@alexcrichton alexcrichton removed I-nominated regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Jul 13, 2018
@bryteise
Copy link
Author

Yea, agreed. Thanks for thinking about it =).

@Mark-Simulacrum
Copy link
Member

@bryteise Is this still an issue for you? We've changed some things around with proc macros since then I believe, in particular we now uplift them to both host and target sysroots I believe, so perhaps that's helped here?

@bryteise
Copy link
Author

@Mark-Simulacrum I'll take a look at building the latest release tomorrow and get back to you.

@bryteise
Copy link
Author

Okay, I think this is fixed (though I may be hitting a different error earlier in the build now hiding it). I'll close this issue though since I can't readily reproduce it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants