Problem with 64 bit gcc 8.4 by dodicat (split from 25215)

[deltarho[1859]]

gcc 7.1 on a win 7 computer seems ok.
gcc 8.1 on a win 10 computer and I can reproduce the issue.

What an astonishing catch.

[srvaldez]

I hope this post is not too offtopic, found personal builds of gcc-7.0 32-bit at https://sourceforge.net/projects/mingw- ... daily/7.x/
and 64-bit at https://sourceforge.net/projects/mingw- ... daily/7.x/
tested dodicat's isaprime without problems
[edit]
building fbc with this toolchain fails

FBC src/compiler/obj/win32/ast-gosub.o

Aborting due to runtime error 12 ("segmentation violation" signal)

make: *** [makefile:616: src/compiler/obj/win32/ast-gosub.o] Error 12

[srvaldez]

@coderJeff thank you :-)
no complaints compiling with the in-progress gcc-11 with -O3

[D.J.Peters]

if someone will try version 9.2.0 it comes from the future ;-)

https://jmeubank.github.io/tdm-gcc/arti ... .0-release

Joshy

[deltarho[1859]]

@Joshy

I had a look at that but when done I needed to do some moving to incorporate it into WinFBE. I didn't know where to start.

What I find worrying is that gcc don't seem to be aware that moving from Win7 to Win10 causes a problem. Many languages use gcc not just FreeBASIC.

[srvaldez]

@deltarho[1859]
in the bin\win64 folder you need besides gcc.exe libiconv-2.dll
in the bin\libexec\gcc\x86_64-w64-mingw32\9.2.0 folder you need
cc1.exe
libgmp-10.dll
libiconv-2.dll
libisl-15.dll
libmpc-3.dll
libmpfr-4.dll

[coderJeff]

@Joshy, thanks for the tip :) I didn't know that TDM was back. I see that downloadable components are available so can still script a build. I may look in to it.

@deltarho
I didn't actually confirm if the issue was win7 versus win10 related. I was just reporting what I tested. I don't really want to install gcc 7.1 on the win10 computer... I'm usually pretty good about keeping tool chains separate, but I didn't want to add any accidental complexity.

Update: I have 32&64 bit mingw-w64 8.1 packages building and 32&64 bit winlib 8.4 packages building now for fbc 1.07.3. Soon as I have that script up to date I'll do the same for fbc 1.08.0.

For 'official' builds I think the 1.08.0 release is going to be:
mingw-w64 gcc-8.1 as the default (as our successor to gcc 5.2)
winlibs gcc 8.4 as additional
mingw-w64 gcc-5.2 as additional only

I've had gcc-7.1 in use for a long time on my win7 computer. but I think I'll just skip over it.

You guys have been doing a great job testing builds and finding the problems. I think the only thing I'm doing extra that probably gives users that 'official' kind of feeling is a few more tests. Building from bootstrap, rebuilding, packaging, installing the package and testing the installation against the test-suite. It's mostly scripted so is not too bad - just long time waiting for builds.

mingw-w64 gcc-8.1 and winlibs gcc 8.4 are 2 different flavours of the tool chain. I have no idea what to expect if one were mixing static libraries or object files between the two. My guess is should probably try to avoid that.

[coderJeff]

in the bin\libexec\gcc\x86_64-w64-mingw32\9.2.0 folder you need

I just went through that with winlibs gcc-8.4. It has a few dependencies not seen on mingw-w64 gcc-8.1.

[srvaldez]

@coderJeff
the tdm toolchain is missing some dx3 headers so the libgfx fails to build
also winlibs uses libwinpthread instead of native win32 threads

[MrSwiss]

I just went through that with winlibs gcc-8.4. It has a few dependencies not seen on mingw-w64 gcc-8.1.

There is however, a reason to avoid any GCC nn.1 version:

• first ever 'official' release, of that whole branch
• untested by the masses (only by dev's-team, test-suite)
• no bugs either 'known' nor 'fixed' (just too raw, IMO)

I'd therefore prefer a more 'mature' version of that branch (8.4 in this case).
This has had tree bug-fix cycles after the initial 8.1 release.

[deltarho[1859]]

in the bin\win64 folder you need besides gcc.exe libiconv-2.dll
in the bin\libexec\gcc\x86_64-w64-mingw32\9.2.0 folder you need
cc1.exe
libgmp-10.dll
libiconv-2.dll
libisl-15.dll
libmpc-3.dll
libmpfr-4.dll

The author wrote "getting back into the groove of delivering a Windows-friendly GCC toolchain".

I wonder how unfriendly would be described.

When a user wants to start their new car for the first time they should expect to use a key, a card or press a button - they should not be expected to lift the bonnet up armed with a spanner.

[deltarho[1859]]

I totally agree with MrSwiss.

If we are going to go for a 8.x successor to 5.2 in fbc 1.08 then we should use 8.3 without any question with 5.2 as additional. I have been using 8.3 for a long time now and have never had to fall back onto 5.2; but it would be expedient to have a safety net. I have not had much experience with WinLibs 8.4 favouring 8.3, built by srvaldez, with smaller binaries.

[coderJeff]

@srvaldez, where is gcc-8.3 from? Is that the one from equation .com?

[srvaldez]

yes
equation solution's make.exe is faulty so I delete it and just use the msys2 make
viewtopic.php?p=272870#p272870

all FB versions built with Equation's toolchains are faulty at interpreting the command line
I just noticed this today while trying to build FBfrog, cd into the src folder and then do fbc *.bas -m fbfrog
you will probably get something like *.bas() error 23: File not found, *.bas
I have removed all the faulty versions from GitHub
the bad versions are gcc 7.4, 8.3, 9.2, 10 and 11

I personally would opt for gcc-8.1 as the default

[srvaldez]

may I suggest as an alteranive toolchain the personal builds by ray_linn gcc-10.2 32-bit https://sourceforge.net/projects/mingw- ... -with-ada/
and the gcc-10.2 64-bit https://sourceforge.net/projects/mingw- ... -with-ada/
these toolchains don't have a bunch of DLL dependencies