morningman commented on PR #67857:
URL: https://github.com/apache/doris/pull/67857#issuecomment-5642384410

   Pushed one more commit to this branch (2a3324457ca) after verifying the 
change locally against the current 
`apache/doris:build-env-ldb-toolchain-latest` (digest `4b35f2…`, CentOS 7.9 / 
glibc 2.17):
   
   **What holds up**
   - `/usr/bin/gcc` (4.8.5) is present in the image (pulled in by libtool), so 
the `CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_LINKER=/usr/bin/gcc` target exists.
   - The LDB toolchain ships its own `lib/libc.so.6` (GLIBC_2.27) and sits 
first in PATH. With Rust 1.91.0 and a crate that only depends on `quote = 
"=1.0.45"`, `cargo build` fails exactly like the CI compile job 
(`build-script-build: version 'GLIBC_2.18' not found`, both `proc-macro2` and 
`quote` build scripts need GLIBC_2.18). With the linker override the same build 
passes and the build scripts need only GLIBC_2.16.
   - The EPEL archive baseurl, the endpoint repo and the full yum package list 
also go through on a clean `centos:7`.
   
   **What the extra commit fixes**
   The TeamCity compile script installs rustup inside this image and then runs, 
as one link of its `&&` chain:
   
   ```
   if curl … https://sh.rustup.rs | sh -s -- -y --default-toolchain stable 
--profile minimal; then source ~/.cargo/env; else echo 'ERROR: …'; fi && …
   ```
   
   With `CARGO_HOME=/opt/cargo`, rustup-init writes `/opt/cargo/env` and 
`~/.cargo/env` never exists, so that `source` fails, the `if` returns 1 and the 
chain aborts before thirdparty or BE are built. I reproduced this verbatim in 
the image (`/root/.cargo/env: No such file or directory`, exit 1, chain 
stopped) — every PR's Compile would fail once this image is published, not only 
thirdparty ones. The commit symlinks `~/.cargo/env` → `${CARGO_HOME}/env` in 
the builder stage (rustup writes the real `/opt/cargo/bin` path into that file, 
so sourcing through the link is correct); re-running the pipeline's line in the 
image now continues the chain, with `/opt/cargo/bin/cargo` resolved and both 
`stable` and `1.91.0` listed (`build_lance_c` keeps pinning 1.91.0 through 
`RUSTUP_TOOLCHAIN`).
   
   Not covered locally: a full `docker build` of this Dockerfile (the 
thirdparty build inside takes hours under emulation). Note that none of the 
GitHub or TeamCity checks on this PR exercise the Dockerfile — the fix only 
takes effect when the image is rebuilt and pushed as `latest`.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to