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

[D.J.Peters]

The only "problem" I ran into was that the generated EXE's were huge because the runtime libraries were statically linked into the EXE.

-shared-libgcc
-shared-libstdc++

Joshy

[coderJeff]

I shall stick to random number generators and cryptography and leave graphics and toolchains to those that know what they are doing.

You presuppose that we (me) know what we (I) are doing. :)

I think cause for the original issue has been found, and I will be doing a full fbc-1.07.3 release to address that. Thank-you dodicat for testing and reporting.

I will also do a full fbc-1.08.0 release soon. It's just been too long waiting. I think we have a path forward for getting to a newer version of gcc for the backend. Thank-you deltarho and srvaldez for testing and reporting on various tool chains.

The equation toolchain is interesting, but I found it has some quirky behaviours when building. I will make a release package for it (on windows), but remark that it is experimental and report my notes. I have a hack that will solve the wildcard expansion for fbc itself. For user programs, you will need to add a bit of code in your main module.

[deltarho[1859]]

My toolchain builder has been busy and sent me another four builds.

Here is a binary size test on one of my applications.

Code: Select all

8.3 ES 133120
8.4 WL 137216
9.3 WL 129536
10.2 WL 133632
10.2 RL 160256
10.3 WL 177152
 
ES Equation Solution
WL WinLibs
RL Ray Linn

9.2 ES and 10.1 ES gave a much larger binary than 8.3 ES and why I favoured 8.3 ES. 9.3 WL is much smaller than 9.2 ES and the smallest binary above.

The 10.2 WL is much smaller than the 10.1 ES but has gone through the roof with 10.3 WL. I have noticed that gcc updates for the same version tend to give smaller binaries but we have a contradiction with 10.3. Ray Linn's 10.2 is large.

The equation toolchain is interesting, but I found it has some quirky behaviours when building.

srvaldez has reservations about ES and seems to be favouring WinLibs.

ES don't update their builds often - they are behind on gcc 8, 9 and 10. WinLibs on the other hand does not let the grass grow much and has newer versions on all three - gcc 10.3 was only updated at gcc HQ two days ago.

On balance, I am starting to favour WinLibs even though, as coderJeff mentioned earlier, "- seems to have the most dependencies".

gcc did not publish 8.4 for the fun of it, so we must assume that it is an improvement on 8.3. Having said that, checking out the changes don't seem to be beneficial for FreeBASIC, but some changes could have been described in Martian for all that I know.

Using 8.x as fbc's new default with 5.2 as an additional will be, I reckon, welcomed by members. Having said that I do wonder at times if many members are that interested. Nearly four days ago I published some builds to add to WinFBE's V2.2.0 which had reverted to gcc 5.2 only. There has been no response; not even from Paul Squires. I have to question whether I should bother doing that in the future - I probably won't.

To my mind then FreeBASIC has a choice between 8.3 ES and 8.4 WL.

For me, I may swing from 8.3 ES to 10.2 WL.

[PaulSquires]

Using 8.x as fbc's new default with 5.2 as an additional will be, I reckon, welcomed by members. Having said that I do wonder at times if many members are that interested. Nearly four days ago I published some builds to add to WinFBE's V2.2.0 which had reverted to gcc 5.2 only. There has been no response; not even from Paul Squires. I have to question whether I should bother doing that in the future - I probably won't.

Sorry David, my lack of response is certainly not an intentional lack of interest in the work that you do. Not by a long shot! I definitely appreciate big time the amount of time and effort that you pour into toolchain evaluation. I made the decision before the most previous WinFBE release to once again follow the toolchain as specified in the official FB release. This is primarily for consistency for new users to FB so that when they use WinFBE then they'll know that the compiler package backend is based on the official FB distribution. Knowing that CoderJeff is looking at changing the toolchain, you can be sure that WinFBE will follow suit.

[deltarho[1859]]

This is primarily for consistency for new users to FB so that when they use WinFBE then they'll know that the compiler package backend is based on the official FB distribution.

OK, I will buy into that slightly. I say slightly because, I reckon, that there are far more existing FB members using WinFBE than there are new users to FB. That is like, nearly, an insurance company or bank giving new customers a cash reward for becoming a new customer but sod all to their loyal customers who may have been with them many years. So, those existing WinFBE users on 2.1.7 and 2.1.8 who were pleased to see gcc 8.4 been used without them having to do anything instead of 5.2, in WinFBE 2.19 and above, which should have been relegated to a museum a long time ago.

To my mind what you should have done was to revert to 5.2 based upon the quote above but included, as an asset, v1.07.2 gcc 8.4; for those using 8.4.

With the upcoming fbc 1.08 using a gcc 8.x version I would change your default to that, but I would include, as an asset, 5.2 for the die hards who won't use anything but 5.2 even if threatened with torture. I think that CoderJeff will include 5.2 as an additional, but that will not be in WnFBE 'format'; that is one folder with fbc32.exe and fbc64.exe.

In other words I would cover the whole market and not sub-markets.

Actually, I would go further and include a gcc version 9.x and 10.x for those adventurous souls who want to go beyond the official FB distribution. Admittedly, they are few and far between and double figures is probably a gross exaggeration.

Also, I would include toolchain asset links in every WinFBE update and not as with 'Alternate GCC Toolchains for WinFBE'. That post is now disappearing into the ether with new and oldish WinFBE users who may not know that post exists.

You are a great Windows programmer Paul but when it comes to marketing .........

[coderJeff]

Most of the files are up:
https://sourceforge.net/projects/fbc/fi ... SIC-1.07.3

Built a couple of windows packages that include both 32-bit (fbc32.exe) and 64-bit (fbc64.exe):
FreeBASIC-1.07.3-equation-8.3.0.7z
FreeBASIC-1.07.3-winlibs-8.4.0.7z

[deltarho[1859]]

@coderJeff

None of the above links work, although you fixed the first link in the FreeBASIC 1.07 Release Discussion thread.

As for the 2nd and 3rd links I posted builds here. However, not everyone reads the WinFBE thread. You could have posted a link to the WinFBE thread because I also threw in WinLibs 10.2 for the adventurous members - all three of them. Am I getting cranky in my old age? Answer: Yes.

Added: Ah, I wonder if you fixed dodicat''s dll problem - my builds don't. If you didn't, then we are running in the same race to deliver the same message so one of us is wasting our time.

[coderJeff]

I've been at this too long. - fixed the links.
I tested that this next version would fix the dll problem from here before starting the builds.

Sorry, I missed your download package. Got it now.
Based on the date it should include the fix for the dll. The fbc's made don't have the commit hash recorded so I don't know what exact version it's from.

Tried out the winlibs-8.4 64-bit only from the TripleBuild.
Seems to work for the -dll -O2 problem in this topic.
Binutils are slightly newer - maybe self compiled? Cross-compiled? (all the text/source are LF only).

Anyway, looks pretty good. Worth someone testing it. Good job.

[deltarho[1859]]

Seems to work for the -dll -O2 problem in this topic.

As does 8.3 ES, 9.3 WL, and 10.2 WL on 1.07.3 where 32-bit is 1.07.2 and 64-bit is 1.07.3

Of course, dodicat's 8.4 build is not the same as my 8.4 build (5 April 2021). WinFBE's 8.4 build is 1.07.1 published 31 May 2020.

dodicat should go to my link in my last post, grab TripleBuild and use FreeBASIC-1.07.3-gcc-8.4

Sorry, I missed your download package.

I am surprised that you don't miss more with what you have on your plate.

Anyway, looks pretty good. Worth someone testing it. Good job.

Don't forget they are my German friend's builds - Mr Anonymous. He writes the books, I just carefully wrap them up and put them into a jiffy bag and post them here.

Worth someone testing it.

Yeah, right. Most members here are more than happy to grab a finished product but get their hands dirty first - no chance.

[srvaldez]

Hi coderJeff
tested the FB gcc-8.3 for wildcard expansion and it works OK, thank you :-)

[deltarho[1859]]

tested the FB gcc-8.3 for wildcard expansion and it works OK

In which case we should see the 1.07 branch in the rearview mirror shortly.

I will let the dust settle on 1.08 and then start my campaign for gcc 10.x.

I invested in a pair of hearing aids recently and heard the remark: "Can we have a whip-round and put a contract out on him".

Tch, tch - dear, oh dear.

[MrSwiss]

Tested coderJeff's code:

Code: Select all

dim as string x(1 to 4)
x(1) = chr(5,5)
Sleep

with FB 1.07.3 32/64 with GCC 8.4 WinLib build, result: OK (aka: no problem)

[coderJeff]

Don't forget they are my German friend's builds - Mr Anonymous. He writes the books, I just carefully wrap them up and put them into a jiffy bag and post them here.

I didn't / won't forget. I just don't know what to do with these builds. If there are any issues with the package I guess you will need to respond to the reports as there is nothing I can do to address it. Unless a bug is reported and pushed back on the compiler development (hopefully recorded on github or sourceforge).
But if there is someone that has interest in making better release packages than I can make, I'm all for it.

[srvaldez]

@coderJeff
you have done an amazing amount of good work, please don't think that some anonymous person is in any way trying to best you in anyway

[deltarho[1859]]

[breaking news]
It is with regret that I must advise that I have received a request from my anonymous German friend to remove any links to his builds.

That is easy with the recent TripleBuild link. However, I have posted links previously and I cannot, off hand, remember where they are. Rather than search for them the safest way is to delete the builds from my web server and that has been done. I opologise for any inconvenience that action may cause.
[/breaking news]