On 23/05/2025 02:59, Yuyi Wang via Cygwin wrote:
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.
You might want to check that the ld flag '--enable-auto-image-base' is
being used here (it's our gcc specsfile, but idk if you are doing
something unusual here)
(otherwise all DLLs end up with the default ImageBase address and you'll
end up with collisions for certain, which we are at the mercy of how the
Windows loader chooses to resolve)
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.
--
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
