Unsolved issues: a call for assistance

[skeeto]

Recent GCC and GDB updates have led to issues that currently have no solutions. I'm also stumped and have run out of avenues to search.

GCC 13.1 does not work on Windows XP (SOLVED)

As of 7256915, GCC no longer runs on Windows XP. Every other program works, just not cc1.exe. When attempting to run this program, (x86) Windows XP reports "The system cannot execute the specified program." with no further details. The same binary works fine on Windows 7 and later. To build your own test:

$ ./multibuild.sh -4q

advzip-compressed GDB 13.1 cannot be decompressed on x64 Windows

The problems began with fdac8e3. I normally advzip -z4 releases to shave about 5% off their size, but after I do this x64 Windows fails to decompress gdb.exe with error 0x80004005. No further information is provided by Windows. It still works on x86 Windows, and so I believe this is an old x64 Windows bug. It dates back at least as far as Windows 7. Until this is solved releases will be a few MiB larger.

More details, including a reduced sample file (advzip.sample) in 2cf762a. To reproduce: Place advzip.sample in a zip file, advzip -z4 that file, then try to decompress using x64 Windows's built-in ZIP support.

It is not feasible to compile GCC 13.1 on a Raspberry Pi 4

As of 13.1, GCC has become so large and complex that it runs out of memory during the bootstrap. So far I've built all the releases on this Raspi4. Not a big deal, but it is sad.

[Peter0x44]

Could the GCC issue possibly be related to the following commit?
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d11e088210a551235d3937f867ee1c8b19d02290
https://gcc.gnu.org/PR108865
I doubt it, but it's worth a further look anyway, I think.

Edit: on second look, this is apparently affecting both the "driver and compiler proper", so I think it would affect more than just cc1.exe if it did cause a problem

[skeeto]

Great find, @Peter0x44! That's the issue! I assumed the driver was simply propagating the error from the compiler, but yes, my description imprecise and it affects both. I'll disable the manifest in the i686 flavor. With this blocker resolved, I'll have a new w64devkit release very soon.

[Peter0x44]

Great! Glad I could help
Perhaps it's an issue worth reporting upstream? or leaving as a comment on the bug tracker?
As far as I can tell, there's no configure option to disable this, and clearly it causes issues on some windows versions
Would using a "side by side" XML manifest file not fix the issue without compromising utf-8 on windows 10?

[skeeto]

Yeah, this seems like an issue they'd be interesting in hearing. I don't see anything on the GCC website or in its documentation listing supported versions of Windows, e.g. that would exclude Windows XP. They punt on this to Cygwin, MinGW, and mingw-w64.

[xparq]

Came here to express my most sincere condolences about the loss of the RPi build. :-/

[MagicalDrizzle]

For the second problem (which I can reproduce), you might want to try ECT instead?
FOSS (Apache), achieves superior compression compared to advzip, and does not trigger the bug on Windows.

C:\Users\X\Downloads\adv>dir /on
09/09/23  03:56 PM           180,000 advzip.sample
09/09/23  04:08 PM           165,029 advzip.zip
09/09/23  04:08 PM           165,029 advzip-ect.zip

C:\Users\X\Downloads\adv>advzip -z4 advzip.zip
      165029      159906  96% advzip.zip
      165029      159906  96%

C:\Users\X\Downloads\adv>ect -9 -zip advzip-ect.zip
Processed 1 file
Saved 18.23KB out of 161.16KB (11.3089%)

C:\Users\X\Downloads\adv>dir /on
09/09/23  03:56 PM           180,000 advzip.sample
09/09/23  04:10 PM           159,906 advzip.zip
09/09/23  04:10 PM           146,366 advzip-ect.zip
               3 File(s)        486,272 bytes
               2 Dir(s)  248,945,229,824 bytes free

[Peter0x44]

Now that the 7z sfx is being used, I guess there is nothing really actionable left in this issue, and it can be closed.

For building on systems with less memory, maybe the solution is to just use less processes (the docker file has make -j$(nproc) hardcoded in both instances where it builds gcc)
I haven't tested this, but I think it's worth a try.

The one thing I'd note is that:

w64devkit/src/variant-x86.patch

Line 15 in 21177fb

+RUN echo >/gcc-$GCC_VERSION/gcc/config/i386/winnt-utf8.manifest

Can be replaced with --disable-win32-utf8-manifest on the configure line.

This won't have a functional change, but I figure it is still better to go through the "official" way of disabling this.

The upstream windows XP issue is here:
https://gcc.gnu.org/PR111170

[skeeto]

Can be replaced with --disable-win32-utf8-manifest on the configure line.

Done (4176ece), thanks! My hack was necessary for GCC 13, but I didn't know about this new switch in GCC 14.

[skeeto]

maybe the solution is to just use less processes

That does work, or at least it did last time I tried. I had to go down to single core builds, and building a full release would take several days. Inconvenient enough to be "infeasible" for me! I expect soon enough it won't be possible to link GCC on 32-bit hosts, so even this work around won't help. That's already been the case with LLVM for some years.