On Wed, 22 May 2025, Jeremy Drake wrote: > Ultimately, playing whack-a-mole in a 64-bit address space hoping that the > DLL will load in the same place as the parent is an exercise in futility, > especially in only 6 attempts.
Outside cygwin, rustc also try 5 times to load the proc macro DLL, so there are 30 attempts. Could this issue be solved by running rebaseall on binaries in `/usr/bin`? Should we introduce `rebase` to rustc? Another idea: is it possible to provide an API to disable reload-on-fork of a specific DLL? Although it might be unsafe, I think it's OK here, because rustc just wants to execute the linker, and in this case the proc macro DLLs won't be used in the new process. In rust-lang/rust#141276, Jeremy Drake wrote: > It seems like in most cases it'd probably use posix_spawn If I were right, posix_spawn also uses fork + exec. That's why I don't think switching to `Command::spawn` would solve this problem. However, the non-POSIX spawn* APIs don't use fork. I'm not sure if it worth a try. As it seems that the linker is executed by LLVM, I think it may be better to patch LLVM. -- Yuyi Wang -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
