gcc 7.1 for the ST series

[ggn]

Okay, just pushed a fix for brownout - could you get, recompile and test please?

Yes, and this time it works flawlessly. Just a warning remaining that complains about comparing gst_name[0] against NULL (should probably be NUL instead?).

Compilers emit warnings as a way to tell you you're doing a good job ((c) dml). Anyway pushed a fix and bumped version!

(BTW: if you think that one little warning is annoying there never try compiling it under Visual studio )

Much thanks for your exemplary fast support!

No problem - many thanks frome me just because you endured me fumbling around!

I shall be giving Fortran another look at some point but my guess is that not that many people are interested! It was a quick and goofy test anyway.


P.S. hope to see your libc working on gcc 7.1

[ggn]

Time passes... and another gcc version is out! gcc 7.2 is released for a while now and we did test our build script with it, just searched and replaced "7.1.0" with "7.2.0". And the tar command needed a new parameter because apparently they don't distribute gcc in bz2 format (at least when I checked). Naturally everything built without a hitch! So if you got to have the latest gcc installed on your machines, you know the drill!

brownbot is of course updated to include this version, and just because we felt like it, we added support for the latest VBCC (0.9f at the time of writing). So if you were ever curious or heard myths about one compiler being better than the other now's the time to put everything to a test .

Finally as an added bonus we added a very old c 68k compiler, c68. The history in the website says it's even predating gcc so it's more of a historical curiosity than anything else. Still it's not too bad!

[troed]

Drill known. bigbrownbuild gcc 7.2.0 for macOS: https://troed.ddns.net/d/6962a15021e04fe38282/

[chicane]

I'm just looking into the idea of compiling my current project (Atari ST Pole Position) using GCC 7.1, mainly with the hope of squeezing out a bit more performance. I've managed to compile the toolchain under Ubuntu, but I'm having problems compiling the assembly language (*.s) files that form part of my project.

Vincent Rivière's m68k-atari-mint cross-tools (which I've been using to date for this project) allow me to specify register names in assembly language files without the '%' prefix (e.g. 'a1', 'd1'), whereas GCC 7.1 appears to require me to specify this prefix (e.g. '%a1', '%d1') in order for these files to compile correctly. Putting aside the idea of doing a find/replace on all of my assembly language files to add a '%' prefix to all register names, are there any switches or configuration settings I can use with GCC 7.1 to accept these files in their current form?

[ThorstenOtto]

are there any switches or configuration settings I can use with GCC 7.1 to accept these files in their current form?

You can try -Wa,--register-prefix-optional in your CFLAGS. But that might not work for inline assembly, only for separately compiled assembler sources.

BTW i still don't understand that effort to compile into elf objects only to have to use a separate tool to create working executables. It's still as easy as before to configure gcc 7.1 to create mint executables just like gcc 4.6.4 did.

[mfro]

BTW i still don't understand that effort to compile into elf objects only to have to use a separate tool to create working executables.

Using ELF objects, you can harness the link time optimisation feature (-flto) which should help optimise large projects and C++ compiles in particular.

[AdamK]

BTW i still don't understand that effort to compile into elf objects only to have to use a separate tool to create working executables.

Using ELF objects, you can harness the link time optimisation feature (-flto) which should help optimise large projects and C++ compiles in particular.

This is not exactly the reason. It is just easier to do that this way.

[ggn]

BTW i still don't understand that effort to compile into elf objects only to have to use a separate tool to create working executables. It's still as easy as before to configure gcc 7.1 to create mint executables just like gcc 4.6.4 did.

Two things come to mind

a) Future proofness. ELF format is going to stay for a long while, but what about a.out?
b) brownout (our elf->tos converter) can be extended to perform some interesting stuff like call map/histogram (so you can see if the compiler calls functions it shouldn't)

[ThorstenOtto]

[a) Future proofness. ELF format is going to stay for a long while, but what about a.out?

Don't know, but i don't really care. Ppl are using gcc 4.6.4 to compile atari software for quite some years now, and in most cases there is still no urgent need to switch to a newer compiler version. There are only some packages that would require c++11 or something which 4.6.4 does not support. For this you could use gcc 7.x generating mint executables as before. There is no need to worry about removal of a.out support until

a) that really happens
b) noone is able to bring it back in using patches.
c) that compiler has some new features that are mandatory to be able to use your current software.

As long as any of the above does not happen, you could still use gcc 7.x

Your approach has some serious disadvantages.

- you can't use *any* of the existing libraries. Everything has to be recompiled, including mintlib, gemlib, and every gnu package you can think of. I don't see any of that libraries.
- ppl have been using rather old packages (zlib 1.2.5 etc) for quite some time now, without anyone trying to update them to new versions. What makes you think that this situation will suddenly change?
- if gcc -o hello hello.c does not produce a working executable, you are in big trouble. You would have to change each and every Makefile for that extra step of invoking your brownout helper.

b) brownout (our elf->tos converter) can be extended to perform some interesting stuff like call map/histogram (so you can see if the compiler calls functions it shouldn't)

Not sure what feature(s) you have in mind, but i'm quite sure you can achieve the same using a.out object files, or some script analyzing the linker map.

[ggn]

[a) Future proofness. ELF format is going to stay for a long while, but what about a.out?

Don't know, but i don't really care.[/url]

That's exactly the reason why this build was started: don't know when/if a.out will be out, don't really care either now - brownout will work for decades. At least for now we had to change 0 lines of code with 2 major revisions of gcc.

Ppl are using gcc 4.6.4 to compile atari software for quite some years now, and in most cases there is still no urgent need to switch to a newer compiler version.

Nobody shoved this gcc down their throats either.

There are only some packages that would require c++11 or something which 4.6.4 does not support. For this you could use gcc 7.x generating mint executables as before. There is no need to worry about removal of a.out support until

a) that really happens
b) noone is able to bring it back in using patches.
c) that compiler has some new features that are mandatory to be able to use your current software.

That's your opinion and I don't really agree with it - firefighting stuff when it happens usually leads to really bad choices. Besides, why are we arguing and talking hypothetically about something that's already done and released, i.e. a bridge between ELF binaries and TOS binaries?

Also again, people are free to do what they want. When we started this there was no gcc 6.2 or 7.1 version in sight, so this is how we proceeded. If someone had released their version(s) sooner you wouldn't see this at all.

As long as any of the above does not happen, you could still use gcc 7.x

Your approach has some serious disadvantages.

- you can't use *any* of the existing libraries. Everything has to be recompiled, including mintlib, gemlib, and every gnu package you can think of. I don't see any of that libraries.

Why is that a disadvantage? I thought the whole idea of using *nix stuff is that people can and are able to compile their libraries.

Also you're a bit incorrect there - mintlib is compiled using the build script. I did also had a go at gemlib but I got stuck somewhere. As gemlib and others wasn't a big concern for me I simply gave up. But hey, my efforts are up here: https://bitbucket.org/ggnkua/bigbrownbuild/src - if someone needs it they can take what I did and fix it further. Or they can start from scratch. You know, open source and all that?

- ppl have been using rather old packages (zlib 1.2.5 etc) for quite some time now, without anyone trying to update them to new versions. What makes you think that this situation will suddenly change?

Again, I'm not forcing this build of gcc to anyone. This build was mostly done for the benefits of 2 people. We just decided it would be nice if we released it to the community. Plus if the libs are open source it's simply a matter of recompiling them, right? And it shouldn't be that hard to fix, right? I mean *nix people are usually skilled in fixing build systems?

- if gcc -o hello hello.c does not produce a working executable, you are in big trouble. You would have to change each and every Makefile for that extra step of invoking your brownout helper.

See my point above - *nix people are used to a bit of torture so that won't be a big hurdle .

Not sure what feature(s) you have in mind, but i'm quite sure you can achieve the same using a.out object files, or some script analyzing the linker map.

Which doesn't say much really! Use one non-existent script against a non-existent feature - does it matter in the end?

Also another possible feature I have written down is packing, so I won't have to keep adding packers with various random switches in each build script. But again, this will be added if people ask for it or we need it ourselves.

[ThorstenOtto]

At least for now we had to change 0 lines of code with 2 major revisions of gcc.

The changes to port the mint patches from gcc 4.6.4 to gcc 7.x where also minimal, so that goal of having a newer compiler could have been achieved which much less effort. Given that there are not such many people around like you that still actively support the atari platform, i consider it just a waste of resources.

Why is that a disadvantage? I thought the whole idea of using *nix stuff is that people can and are able to compile their libraries.

Yes, *their* libraries, but not *all* libraries they want to use in their project, like zlib, libpng etc. Not all them compile out of the box for atari by just doing configure/make. Not to speak about mintlib/gemlib.

I did also had a go at gemlib but I got stuck somewhere. As gemlib and others wasn't a big concern for me I simply gave up. But hey, my efforts are up here: https://bitbucket.org/ggnkua/bigbrownbuild/src

I don't see any source or patches there, only some scripts.

Plus if the libs are open source it's simply a matter of recompiling them, right?

A compiler alone isn't that really useful without any library to build an executable, not even a C-library.

[leech]

I'm probably going to regret this (not a fan really) but wouldn't this be a good usage of something like Docker? Creating a docker image for compiling Atari/MiNTlib stuff would be pretty useful, actually.

Here I get all excited, then see that GCC 7.2 was being installed when I ran updates on my Debian Sid box

[mikro]

Actually I welcome ggn's & dml's initiative. This made me curious whether the situation described in http://d-bug.mooo.com/beyondbrown/post/gcc-6/ is really that bad (it isn't) which consequently led to looking into gcc7, then Thorsten came with his patch so that fast-forwarded everything and now I'm enjoying m68k-atari-mint-gcc 7.1 in the same way as 4.6.4 before, only with better code generator and some annoying bugs fixed (I must really emphasise the great work Thorsten has done when an issue or two appeared). After I'm done with testing, I'll release also native binaries for 68000, 68020-60 and the FireBee, as before.

[leech]

Oh, I guess Vincent's Repo isn't updated with GCC7 yet then? For some reason I was thinking it was.

Granted last time I tried compiling something (QED) it couldn't find cflib, which I'm sure I have installed.

[ThorstenOtto]

Oh, I guess Vincent's Repo isn't updated with GCC7 yet then? For some reason I was thinking it was

He has newer versions of binutils already (2.28), but not yet a newer version of gcc. Of course mikro or me could have published it too, but i think he has already plans for that, and his tools page is already well known, so i didn't want to "steal" it from him.

[leech]

Oh, I guess Vincent's Repo isn't updated with GCC7 yet then? For some reason I was thinking it was

He has newer versions of binutils already (2.28), but not yet a newer version of gcc. Of course mikro or me could have published it too, but i think he has already plans for that, and his tools page is already well known, so i didn't want to "steal" it from him.

Thanks! I have to say between all of you, it's what keeps a lot of the ST line alive and useful in the modern age! Well relatively more so than it would have otherwise.

While there is serious amounts of infighting in the Amiga community, it seems most of the people have come together in the Atari community to push the platform forward.

[ggn]

At least for now we had to change 0 lines of code with 2 major revisions of gcc.

The changes to port the mint patches from gcc 4.6.4 to gcc 7.x where also minimal, so that goal of having a newer compiler could have been achieved which much less effort. Given that there are not such many people around like you that still actively support the atari platform, i consider it just a waste of resources.

Ok, dude, that's harsh.

First of all it's mine and Doug's free time and we do whatever we damn want with it - I for one don't need a project manager to consider me as a "resource" and tell me what to do with my Atari time .

Furthermore let me re-iterate the situation again and spice it up with some extra info:

About a year ago (I think that's when we started messing around with this project) there was no released gcc 6.x or 5.x for Ataris. We tried to forward patch binutils but since diff/patch/linux/etc ain't our thing we got a bit stumped and just couldn't proceed. Nor we wanted to know what's under the hood of binutils and fix it. We just wanted a modern gcc for our projects.

We tried a couple of other ideas, searched around the internet etc but nothing really hopeful came up. Around that time I spoke to a guy on irc who told me that he hacked a python script to convert elf to prg files (https://github.com/iamgreaser/stelf). Me and dml also were leaning towards that idea but we both don't like python that much. So after we got the m68k-elf part of binutils and gcc and mintlib running we set out writing brownout. It was tricky in parts but it really wasn't that impossible to do (plus we had proof it can be done!). So that was that.

After all this was in place dml went to work on it, adjusting his startup code and modifying his build scripts so his agt codebase would compile and run properly with this toolchain. Hell, I even took the extra mile and added elf .o support to the assembler him and a few other people use, rmac. All in all this resulted to a quite stable platform.

And that would have been it - just keep it for ourselves and use it and be happy. But I thought that we should release this to the community in order to give something to the people, see if they need it, or at least know that it would be there if they needed it. We even wrote a detailed article to document this process and give people usage instructions. And hey, we got all that ready for Christmas!

So, all in all this resulted in keeping motivated one of the most gifted programmers this platform ever had and spawned a few fun projects that gave him (amongst others) quite useful insights into optimising code for the compiler. I'm also using agt for a project - not announced or released yet but hey, it's "coming soon".

To conclude, in my (very) humble opinion it really wasn't a waste of resources. You want to know what a waste of resources is: typing this lengthy reply to justify myself (and dml)

Yeah, there are a couple of points in your last reply I could retort and, who knows, start a flamewar or polarise the thread etc etc. But sorry, I won't go down that road. And you know what? I'm sure that if we all got together in a party or Atari meeting or whatever we'd just have a talk, laugh about it and move on. People sitting behind monitors and not seeing each other cannot really deduce what the others think or say if they can't look each other in the face (plus the language barrier some times), thus arguments heat up. But I won't rathole myself into this. We're big boys now, let's agree to disagree and move on and do something constructive and interesting with our free times instead

Regards everyone,
George

[wongck]

After I'm done with testing, I'll release also native binaries for 68000, 68020-60 and the FireBee, as before.

Great. But help me understand.

I use several libraries that I got from (the old) Sparemint.
Do I need new libraries for them?

Also does the current gdb works for the new gcc7.x binaries ?

[mikro]

wongck: you can use sparemint libraries (although I really wouldn't recommend that, 10+ years old now).

gdb refuses to play nice since gcc 4.x so if you really, really want to debug stuff natively, gdb 2.95 + sparemint gdb is the only way I'm afraid. :-( Maybe you can use newer gdb but the old gcc is mandatory.

[wongck]

Thanks for the answer.

Unfortunately my development is on the Atari platform. I think v2,95 is no longer on my disk as I am using v4.5 (or something like that). gdb seems to be working on it fine for me.... or may be I am not a super gdb user that use it to the full potential. Basically just to see which line of code makes the dev prg fails.
So looks like I be sticking to this old version.
LOL... I do not really remember how I hack together my current version either.

[mikro]

I am using v4.5 (or something like that). gdb seems to be working on it fine for me....

To what extent? It's not like gdb doesn't work at all with newer GCCs, it's just... buggy. For instance you set a breakpoint and it's missed. Or you are tracing code and it suddenly jumps etc. So if your gcc 4.5 really works at least as good as 2.95, I'd say it's worth investigation. Where did you get it from? My public builds started from 4.3.2, will give it a try too.

[wongck]

To what extent? It's not like gdb doesn't work at all with newer GCCs, it's just... buggy. For instance you set a breakpoint and it's missed. Or you are tracing code and it suddenly jumps etc. So if your gcc 4.5 really works at least as good as 2.95, I'd say it's worth investigation. Where did you get it from? My public builds started from 4.3.2, will give it a try too.

yes, it exhibited everything you mentioned, so it is just as buggy as anyone's.
LOL... and all along I thought it was mainly some compiler optimisation not turned off & me not knowing how to use Unix style tools.
I uses it when my dev prg crash, and do a bt to see what's up with it.
Half the time it cannot de-reference to the code anyway, but when it does, it shortens debugging time.

Still something is better than nothing. The tools are rather weak, but i get by.

[ThorstenOtto]

Ok, dude, that's harsh.

You are right. I apologize, but's that's just my POV.

First of all it's mine and Doug's free time and we do whatever we damn want with it

Of course. I just wished that ppl developing for the atari platform, and then publish their work, would do something more useful. Your browngcc might be a interesting thing, but in practise it is not usable.

But I thought that we should release this to the community in order to give something to the people, see if they need it, or at least know that it would be there if they needed it.

Maybe i i'm doing something wrong, but for me it does not work. I actually downloaded the toolchain (the 6.2 version for linux). The first thing i noticed that there is a library /usr/lib/libc11.so. That is absolutely unacceptable for a cross compiler, since it would overwrite your native compilers version, making it unusable. You should really fix that (--disable-libcc1 will help).
And then i'm not able to produce a working executable the usual way. If i do that, gcc tries to link crtbegin.o in as the startup code, instead of crt0.o from mintlib. I have to specify -nostdlib and link everything by hand, including maybe target specific versions of the library.

And hey, we got all that ready for Christmas!

You sound as if all that was just doing us a favour. But you forget that you are working with GPLed software. Of course you can do everything you want with it, but as soon as you publish it you are *forced* to also publish the source, otherwise you are in violation of GPL. And i still see don't see any patches in your repo, only some scripts. Those scripts certainly don't work as is, since neither binutils nor gcc will recognize a "m68k-ataribrowner-elf" target.

Having that said, i really appreciate your work, but i just think it is going in the wrong direction. And i think it has some bugs that should be fixed before it can be used by anything but self-contained projects. So people should just be told that in its current state, it is *not* a replacement for the currently used gcc 4.6.4 cross-compiler.

Thorsten

[troed]

Of course you can do everything you want with it, but as soon as you publish it you are *forced* to also publish the source, otherwise you are in violation of GPL. And i still see don't see any patches in your repo, only some scripts. Those scripts certainly don't work as is, since neither binutils nor gcc will recognize a "m68k-ataribrowner-elf" target.

If you want to learn more about open source licensing, please feel free to ask. There are absolutely no issues with GPL and the brown-project.

/Troed

[ggn]

Ok, dude, that's harsh.

You are right. I apologize, but's that's just my POV.

Sure, but still.

First of all it's mine and Doug's free time and we do whatever we damn want with it

Of course. I just wished that ppl developing for the atari platform, and then publish their work, would do something more useful. Your browngcc might be a interesting thing, but in practise it is not usable.

Says who? Like I wrote above, Doug's AGT builds fine with in on linux and windows. A project I'm working on using agt works totally fine with it. So, sorry but you're dead wrong.

But I thought that we should release this to the community in order to give something to the people, see if they need it, or at least know that it would be there if they needed it.

Maybe i i'm doing something wrong, but for me it does not work. I actually downloaded the toolchain (the 6.2 version for linux). The first thing i noticed that there is a library /usr/lib/libc11.so. That is absolutely unacceptable for a cross compiler, since it would overwrite your native compilers version, making it unusable. You should really fix that (--disable-libcc1 will help).

Well fair enough, I don't use linux as my primary O/S and just provided these binaries as help to beginners or people who don't want to compile gcc on their own. This has been fixed in the way of "choose another directory to install gcc rather than /usr". I'll take the old binaries down and let people compile it on their own.

And then i'm not able to produce a working executable the usual way. If i do that, gcc tries to link crtbegin.o in as the startup code, instead of crt0.o from mintlib. I have to specify -nostdlib and link everything by hand, including maybe target specific versions of the library.

The build script repository contains a "barebones" example on how to build a simple application. This is proven to work. I don't know exactly what you tried but clearly you didn't have any time to look at the supplied material.

And hey, we got all that ready for Christmas!

You sound as if all that was just doing us a favour. But you forget that you are working with GPLed software. Of course you can do everything you want with it, but as soon as you publish it you are *forced* to also publish the source, otherwise you are in violation of GPL. And i still see don't see any patches in your repo, only some scripts. Those scripts certainly don't work as is, since neither binutils nor gcc will recognize a "m68k-ataribrowner-elf" target.

Right, so one can't patch gcc using sed commands? Like I wrote above I'm really uncomfortable with .diff files and applying them using patch. They make me feel like I have 0 control and I have no desire to learn to read and understand them effectively by hand. So I just wrote a bunch of sed commands to do it inside the script. People that contributed to the script (namely Patrice Mandin and Troed of SYNC) certainly got what I did and provided fixes and improvements. Sorry to say but you're alone in this!

As for licensing stuff, boy you do seem to be quite touchy so I won't even comment on that.

Having that said, i really appreciate your work, but i just think it is going in the wrong direction. And i think it has some bugs that should be fixed before it can be used by anything but self-contained projects. So people should just be told that in its current state, it is *not* a replacement for the currently used gcc 4.6.4 cross-compiler.

Thorsten

All these posts you made didn't give me that impression at all. More like me and Doug (ok, let's say it's just me - let's not soil Doug's name here) made a faux pas against something and now I have to pay the price for it dearly by people that will start nitpicking everything I did and throwing pseudo legal threats at me. I did give you a fair chance with my previous post to concede this discussion on a light note but you keep throwing straw man arguments at me. Sorry, but you'll have to continue on your own for now. I think we said quite enough about this here. If you want to continue this on your own feel free to open a new thread and rant about how much my versions of gcc sucks and how I should not be allowed on the intenets or something. But please, this is a thread for announcing new stuff from this project, not your personal soapbox where you can complain about stuff.

Let me stress that I don't have anything against you or your stuff but I really don't get this line of interrogation from you. Let's just drop it here?