1.43.0 x.py "dist" build fails in LlvmTools build #71743

Activity

1. he32

   added

   C-bugCategory: This is a bug.Category: This is a bug.

   on May 1, 2020
2. jonas-schievink

   added

   A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.

   T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

   on May 1, 2020
3. Mark-Simulacrum commented on May 1, 2020

   

   Mark-Simulacrum

   on May 1, 2020

   Member

   More actions

   Since this did work on our dist builders, presumably, I'm a bit surprised to see this. Are you applying any patches atop our build? Maybe LLVM has some internal detection which isn't running? (Can you see if the llvm/bin dir, not in build is being created with x.py build? It seems like we expect that to be the case.)
4. he32 commented on May 1, 2020

   

   he32

   on May 1, 2020 via email

   Last edited by he32

   ContributorAuthor

   More actions

   Since this did work on our dist builders, presumably, I'm a bit surprised to see this. Are you applying any patches atop our build?

   Yes, I'll have to admit that we do. https://github.com/NetBSD/pkgsrc/tree/trunk/lang/rust is our set of build scaffolding and patches to make this build on NetBSD. This worked with 1.42.0.

   Maybe LLVM has some internal detection which isn't running? (Can you see if the `llvm/bin` dir, not in build is being created with `x.py build`? It seems like we expect that to be the case.)

   Hmm... I find an llvm/bin/llvm-nm in d3: {4} find work -path '*/llvm/bin/llvm-nm' work/.destdir/usr/pkgsrc/lang/rust/work/rustc-1.43.0-src/build/x86_64-unknown-netbsd/llvm/bin/llvm-nm d3: {5} So parts of the build appears to respect ${DESTDIR}, but some other part doesn't(?) Regards, - Håvard
5. Mark-Simulacrum commented on May 1, 2020

   

   Mark-Simulacrum

   on May 1, 2020

   Member

   More actions

   Hm, so I'm not seeing anything initially suspicious at a quick glance through. We ourselves don't set DESTDIR, though, and maybe that's being threaded through to the LLVM build and causes trouble?

   AFAICT, x.py dist just uses the existing pre-built llvm -- I would expect that if x.py build worked (i.e. created the file where x.py dist expected it) x.py dist would just work too.

   Did you start setting DESTDIR since 1.42 (or perhaps something else in your environment changed)?

   I pretty much see nothing suspicious on our end in the diff between 1.42 and 1.43 (at least in src/bootstrap). LLVM didn't even have any significant changes between those two tags as best as I can tell...
6. he32 commented on May 2, 2020

   

   he32

   on May 2, 2020 via email

   ContributorAuthor

   More actions

   Hm, so I'm not seeing anything initially suspicious at a quick glance through. We ourselves don't set DESTDIR, though, and maybe that's being threaded through to the LLVM build and causes trouble? AFAICT, x.py dist just uses the existing pre-built llvm -- I would expect that if x.py build worked (i.e. created the file where x.py dist expected it) x.py dist would just work too.

   I'm using "dist" instead of "build", not doing "dist" after first doing "build".

   Did you start setting DESTDIR since 1.42 (or perhaps something else in your environment changed)?

   DESTDIR is always set when building in pkgsrc, so it's always been set earlier.

   I pretty much see nothing suspicious on our end in the diff between 1.42 and 1.43 (at least in src/bootstrap). LLVM didn't even have any significant changes between those two tags as best as I can tell...

   Hmm... - Håvard
7. Mark-Simulacrum commented on May 2, 2020

   

   Mark-Simulacrum

   on May 2, 2020

   Member

   More actions

   I'm using "dist" instead of "build", not doing "dist" after first doing "build".

   Yes, dist internally just "runs" build (not on the command line, but the same effect, I think).

   Yeah, I guess -- one thing that could be helpful is to try to bisect this? I imagine it would take a long time though, given how slow building the compiler can be.
8. he32 commented on May 10, 2020

   

   he32

   on May 10, 2020

   Last edited by he32

   ContributorAuthor

   More actions

   It looks like this problem has been there for a while; it's also present in 1.41.1,
   and probably in earlier versions as well (I didn't check earlier versions).

   I've replicated it outside of the pkgsrc setup, and it's indeed being triggered by
   a non-null DESTDIR in the environment passed to x.py when doing the "dist" target.
   I have a workaround for the pkgsrc context by unset'ing DESTDIR.

   However, that workaround apparently has the unfortunate consequence that
   the time to install suddenly got significantly prolonged, because cargo detects
   a difference in the environment between the "build" and "install" phases, and
   decides that "everything needs a re-build on install".
9. Mark-Simulacrum commented on May 10, 2020

   

   Mark-Simulacrum

   on May 10, 2020

   Member

   More actions

   Ah, okay. Sounds like we probably need to unset DESTDIR internally when building LLVM? I'd be happy to accept a PR for that, but probably won't get to it myself.
10. jyn514 commented on May 20, 2023

    

    jyn514

    on May 20, 2023

    Member

    More actions

    I'm going to close this in favor of #73132.
11. jyn514

    closed this as not plannedon May 20, 2023