Problem building 1.86.0 on Darwin due to problematic usage of DYLD_LIBRARY_PATH in bootstrap

[debohman]

Summary

Bootstrap is placing system directories such as /usr/local/lib into DYLD_LIBRARY_PATH, which allows stem name matching of libraries and can result in the incorrect version of system libraries being located during a lookup.

Here is the case I ran into:

Process:               cargo [54976]
Path:                  /usr/local/bin/cargo
Identifier:            cargo
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        ??? [54975]
Responsible:           cargo [54976]

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x4] Symbol missing

Application Specific Information:
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/tera/tera/debo/Projects/rustc/rustc-1.86.0-src/build/x86_64-apple-darwin/stage0-bootstrap-tools/x86_64-apple-darwin/release/deps:/usr/local/lib

Dyld Error Message:
  Symbol not found: __cg_jpeg_resync_to_restart
  Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /usr/local/lib/libJPEG.dylib
 in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

Normally, the dynamic linker locates libraries using the absolute path recorded in an executable or another dynamic library, but setting DYLD_LIBRARY_PATH subverts that, because those directories are searched first using stem matching. This is intended to allow the use of special libraries, but it is not clear why bootstrap is placing a system library location (/usr/local/lib) into the path. In this case, the failure is due to the fact that the system ImageIO framework has its own copy of libjpeg, but putting /usr/local/lib in DYLD_LIBRARY_PATH causes /usr/local/lib/libjpeg.dylib to be located first using stem matching.

I was able to work around the problem by changing bootstrap to instead use DYLD_FALLBACK_LIBRARY_PATH and setting that to the appropriate search path in the environment before invoking the build. This works because DYLD_FALLBACK_LIBRARY_PATH is searched after the pathname searching is performed.

It is probably okay to place special build directories needed by bootstrap into DYLD_LIBRARY_PATH, but don't put any other locations there.

Command used

DESTDIR=/tmp/dst.rustc x.py install

Operating system

macOS 10.12.6

HEAD

Tarball build of 1.86.0:

05f9846

Additional context

Build Log

Vendoring sources to "/tera/tera/debo/Projects/rustc/rustc-1.86.0-src"
   Vendoring rust_team_data v1.0.0 (https://github.com/rust-lang/team#a5260e76) (/tera/tera/debo/.cargo/git/checkouts/team-679b79b2e58466cd/a5260e7/rust_team_data) to /tera/tera/debo/Projects/rustc/rustc-1.86.0-src/build/tmp/generate-copyright-vendor/rust_team_data-1.0.0
To use vendored sources, add this to your .cargo/config.toml for this project:

Building stage0 tool generate-copyright (x86_64-apple-darwin)
    Finished `release` profile [optimized] target(s) in 6.72s
Error: Failed get output from cargo-metadata: CargoMetadata { stderr: "dyld: Symbol not found: __cg_jpeg_resync_to_restart\n  Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n  Expected in: /usr/local/lib/libJPEG.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n" }

Caused by:
    `cargo metadata` exited with an error: dyld: Symbol not found: __cg_jpeg_resync_to_restart
      Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
      Expected in: /usr/local/lib/libJPEG.dylib
     in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:20:31

[bjorn3]

Why is cargo getting linked against libjpeg in the first place? Cargo has absolutely no need to encode or decode jpeg images.

Bootstrap is placing system directories such as /usr/local/lib into DYLD_LIBRARY_PATH

That is because the bootstrap compiler you are using is located in /usr/local/bin. Rustc is dynamically linked against librustc_driver-*.dylib, which is located in /usr/local/lib if rustc itself is in /usr/local/bin. Rustc may be compiled without rpath while at the same time not being installed system wide, in which case DYLD_LIBRARY_PATH is necessary for the dynamic linker to find librustc_driver-*.dylib. Rustup also sets it.

[debohman]

I am not certain about what is pulling in the ImageIO framework, it is likely one of the other system frameworks. Cargo is linked against the system Security framework and also the CoreFoundation framework. Here is the list of the libraries referenced by Cargo:

% otool -L /usr/local/bin/cargo                                                                   
/usr/local/bin/cargo:
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.60.23)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.92.0)
	/usr/local/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/usr/local/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.1)
	/usr/local/lib/libcurl.4.dylib (compatibility version 13.0.0, current version 13.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)

The real problem I see is putting system directories into the DYLD_LIBRARY_PATH. Why not just allow the full pathname resolution to occur, or the normal fallback path in the dynamic linker which occurs after the normal pathname resolution?

[bjorn3]

Why not just allow the full pathname resolution to occur, or the normal fallback path in the dynamic linker which occurs after the normal pathname resolution?

Because if rustc was compiled without rpath enabled and it isn't installed into a system location, the dynamic linker would fail to find librustc_driver-*.dylib.

[debohman]

Understood, but that belongs in DYLD_FALLBACK_LIBRARY_PATH.