On Fri, 23 May 2025, Yuyi Wang wrote:
> On Fri, 23 May 2025, Jeremy Drake wrote:
> > Maybe. MSYS2 doesn't generally advise to rebase on x86_64, but I think
> > Cygwin does as part of its setup/postinstall hooks. As a hack, I was able
> > to work around this by setting the "dynamicbase" flag on t
On Fri, 23 May 2025, Jeremy Drake wrote:
> Maybe. MSYS2 doesn't generally advise to rebase on x86_64, but I think
> Cygwin does as part of its setup/postinstall hooks. As a hack, I was able
> to work around this by setting the "dynamicbase" flag on the dlls (it's a
> long story about why this hel
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 al
On Fri, 23 May 2025, Yuyi Wang 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
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 t
On Wed, 21 May 2025, Jeremy Drake via Cygwin wrote:
> On Wed, 21 May 2025, Jeremy Drake via Cygwin wrote:
>
> > the child to not be very fruitful, but maybe there's some debugging to be
> > done there
>
> Well, found the bug that results in a 0 size. size is a DWORD, but
> mb.RegionSize is 0x2000
On Wed, 21 May 2025, Jeremy Drake via Cygwin wrote:
> the child to not be very fruitful, but maybe there's some debugging to be
> done there
Well, found the bug that results in a 0 size. size is a DWORD, but
mb.RegionSize is 0x2. mb.RegionSize is SIZE_T, but I figure
size_t is appropria
On Tue, 20 May 2025, Yuyi Wang wrote:
> Thank you for your reply. The DLL is a "proc macro" DLL for rustc, which means
> that it's not designed to be changed after created. However, I've also found
> that this stage-1 compiler doesn't always trigger this failure: it just
> trigger
> fork failure
I tried dlfork(FORK_NO_RELOAD) after dlopen() the proc macro DLLs. Now rustc
works as expected. Therefore, I think the problem is most likely caused by too
many DLLs loaded. See the PR here: https://github.com/rust-lang/rust/pull/141276
I think dlfork is a good workaround, but not the best. It wou
On 2025-05-19 21:25, Yuyi Wang via Cygwin wrote:
Thank you for your reply. The DLL is a "proc macro" DLL for rustc, which means
that it's not designed to be changed after created. However, I've also found
that this stage-1 compiler doesn't always trigger this failure: it just trigger
fork failure
Thank you for your reply. The DLL is a "proc macro" DLL for rustc, which means
that it's not designed to be changed after created. However, I've also found
that this stage-1 compiler doesn't always trigger this failure: it just trigger
fork failure with compiling relatively large projects. In this
On Mon, 19 May 2025, Yuyi Wang via Cygwin wrote:
> Recently I'm trying to build rustc on Cygwin (actually MSYS2). Here is the
> error:
>
> 0 [main] rustc 3299 child_info_fork::abort: couldn't allocate memory
> 0x1FD10(0) for
> '\??\D:\Straw\Documents\Git\rust\build\x86_64-pc-cygwin\st
Recently I'm trying to build rustc on Cygwin (actually MSYS2). Here is the
error:
0 [main] rustc 3299 child_info_fork::abort: couldn't allocate memory
0x1FD10(0) for
'\??\D:\Straw\Documents\Git\rust\build\x86_64-pc-cygwin\stage1-rustc\release\deps\zerovec_derive-4b870d338ef8cbdd.dll'
13 matches
Mail list logo
