gcc 7.1 for the ST series

C and PASCAL (or any other high-level languages) in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

gcc 7.1 for the ST series

Postby ggn » Sat Jul 15, 2017 5:41 am

Here we are with gcc 7.1, the latest stable release of gcc to date ready for your Ataris! It was kind of supposed to be released at Sommarhack last week but we completely forgot about it :).

Like before, head to http://d-bug.mooo.com/beyondbrown/post/gcc7/ for the writeup and links and you're also welcome to try it live at http://brownbot.hopto.org

Enjoy!

ggn + dml
is 73 Falcon patched atari games enough ? ^^

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4849
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: gcc 7.1 for the ST series

Postby simonsunnyboy » Sat Jul 15, 2017 9:31 am

That sounds great, esp. the improved code generation! Are Ubuntu packages coming, or is a build from source required?
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Sat Jul 15, 2017 11:04 am

simonsunnyboy wrote:Are Ubuntu packages coming, or is a build from source required?


Well, that's a bit of a tricky issue: what packages do people need and if they downloaded prebuilt ones for 6.2. People could use 64bit, 32bit (not that common but you never know), Ubuntu 14, 16, perhaps older ones, Centos, etc etc, the list goes on.

I have a Linux Mint install based on Ubuntu 14.x and a Linux Elementary at work (which is based on Ubuntu 16.x I think?) - both 64bit so I can make some binary distributions for people. And I also built everything for raspberry pi (brownbot uses that) so I can package those too. Of course there's the other thing of where do people like their installations to reside. We got quite some criticism of using /usr for 6.2 and we now provide the option of manually editing install path before building.

So that's what I got. If people can agree on an install directory and the distro they use I will make an effort to package something up.
is 73 Falcon patched atari games enough ? ^^

User avatar
dhedberg
Atari Super Hero
Atari Super Hero
Posts: 537
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: gcc 7.1 for the ST series

Postby dhedberg » Sat Jul 15, 2017 1:03 pm

Awesome work. Thanks guys!
Daniel, New Beat - http://newbeat.atari.org

User avatar
shoggoth
Nature
Nature
Posts: 853
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: gcc 7.1 for the ST series

Postby shoggoth » Sat Jul 15, 2017 9:14 pm

Amazing.

Hat off, bow. and bend over.
Ain't no space like PeP-space.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4849
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: gcc 7.1 for the ST series

Postby simonsunnyboy » Sun Jul 16, 2017 8:01 am

Statically linked binaries for 64 and 32bit to be placed into /opt would be ok for me. As long as it does not want obscure dynamically linked libraries, I personally will not need fully fledged packaging although it is nice to have. Maybe you can team up with Vincent Riviere?
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Mon Jul 17, 2017 4:10 pm

simonsunnyboy wrote:Statically linked binaries


Sorry if I'm misunderstanding this, but isn't static linking on linux a big no-no and against one of its core philosophies? At least in my mind, gcc would have to be statically linked against all libraries including libc, and from what I know libc tends to change over time or get patched. And if you're doing that (again AFAIK) you're essentially locking it down to a single libc version that could be really bad news if you upgrade your system.

(Again, anyone is free to correct me on the subject, but I always thought that static linkage on linux is a terrible idea :))

simonsunnyboy wrote:for 64 and 32bit


Any particular reason you need both versions or just "good to have"?

simonsunnyboy wrote:to be placed into /opt would be ok for me.


That's reasonable enough. Although at least here the location seems to need root privileges - one of the main things people didn't like about the 6.2 release...

simonsunnyboy wrote:As long as it does not want obscure dynamically linked libraries,


AFAIK gcc is as self contained as possible - only during compile time you might need extra libs/packages.

simonsunnyboy wrote:I personally will not need fully fledged packaging although it is nice to have.


Well make up your mind - packaging is a complex process and it's not to be taken lightly :). Also you didn't specify the package type - debian, rpm, archlinux, tarball, other? Note also that I have no experience with this so it's an extra time investment for me for something that will probably bring little in return (unless many people ask for this of course - this wasn't the case with 6.2 though)

simonsunnyboy wrote:Maybe you can team up with Vincent Riviere?


Like I said above, packaging can be quite complex and time consuming. I really wouldn't dare asking Vincent to devote what I perceive would be a good chunk of his spare time for this.
is 73 Falcon patched atari games enough ? ^^

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: gcc 7.1 for the ST series

Postby dml » Mon Jul 17, 2017 4:29 pm

simonsunnyboy wrote:Statically linked binaries for 64 and 32bit to be placed into /opt would be ok for me. As long as it does not want obscure dynamically linked libraries, I personally will not need fully fledged packaging although it is nice to have. Maybe you can team up with Vincent Riviere?


Re: obscure libs - we didn't add anything new and weird (libbananapeeler.a!) so its just the same gnu stuff that turns up with any other version of the gcc compiler. One exception may be the brownout tool which isn't part of gnu - but I don't remember that having much, if anything, in the way of dependencies (not entirely keen on dependencies!).

BlankVector
Captain Atari
Captain Atari
Posts: 397
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: gcc 7.1 for the ST series

Postby BlankVector » Tue Jul 18, 2017 9:57 am

ggn wrote:
simonsunnyboy wrote:Maybe you can team up with Vincent Riviere?


Like I said above, packaging can be quite complex and time consuming. I really wouldn't dare asking Vincent to devote what I perceive would be a good chunk of his spare time for this.

Well, GCC Brown Edition and m68k-atari-mint-gcc are different variants.
But regarding to Debian/Ubuntu packaging, I have recently moved all m68k-atari-mint source packages to GitHub. That may be used by other people as source of inspiration.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4849
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: gcc 7.1 for the ST series

Postby simonsunnyboy » Tue Jul 18, 2017 2:59 pm

In the past I had various issues with non-packaged Linux apps that were dynamically linked.
Package build on superhyper Fedora something but does not work on stable Debian, because of dynamically linked libs that are unavialble etc....

For software packages not coming from the distribution, I think statically linked is ok if it allows software to work out of the box. Packages for a specific distribution ofcourse should be dynamically linked.

32bit is not a must but might be for others or for virtual machines....I personally only use AMD64.

Regarding /opt, I don't see a problem there. I normally assign it another user group, place myself inthat group and now I can install software therw without root privileges. Being able to install under $HOME/bin/.... woudl alos be nice. I hate non-distro package to clutter /usr/... hierarchy.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1544
Joined: Sun Jul 31, 2011 1:11 pm

Re: gcc 7.1 for the ST series

Postby Eero Tamminen » Tue Jul 18, 2017 9:28 pm

Static linking doesn't work for Glibc. It loads several parts of itself dynamically, I think at least related to name resolution, localization and crypto.

But GCC is anyway pretty self-contained, and anything it depends on, should be well library API/version controlled etc. I.e. it should be fine as dynamically linked, as long as linking is done on a reasonable LTS version so that minimum version dependency isn't too new.

(LLVM would be another matter, mainly because it's C++ and ABI changes for C++ stuff are pretty frequent and IMHO often messy.)

User avatar
farvardin
Captain Atari
Captain Atari
Posts: 348
Joined: Fri Jan 01, 2010 5:50 pm
Location: France
Contact:

Re: gcc 7.1 for the ST series

Postby farvardin » Sun Jul 23, 2017 10:12 pm

do the generated binaries work on standard ATARI STF with TOS 1.00 or do they require to use Mint and unix subsystem?

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Mon Jul 24, 2017 2:39 pm

farvardin wrote:do the generated binaries work on standard ATARI STF with TOS 1.00 or do they require to use Mint and unix subsystem?


If you check out the repository for the builder you can find a folder called "barebones" that has a few examples that build with very few dependencies (you can also check out the write up at the link on the first post for more details). If you decide to use mintlib then yes MiNT might be required (although I suspect that it still does work under plain TOS as long as you don't use MiNT specific stuff).

To answer your question: yes, binaries will work on plain ST :).
is 73 Falcon patched atari games enough ? ^^

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: gcc 7.1 for the ST series

Postby troed » Mon Jul 24, 2017 3:17 pm

barebones, compiled on my Mac. I think the file sizes give it away ;)

Code: Select all

tmbpr:dev troed$ cd bigbrownbuild/
tmbpr:bigbrownbuild troed$ cd barebones/
tmbpr:barebones troed$ cd auto/
tmbpr:auto troed$ ls -la
total 48
drwxr-xr-x   6 troed  staff   204 Jul 16 19:00 .
drwxr-xr-x  24 troed  staff   816 Jul 17 22:29 ..
-rw-r--r--   1 troed  staff  7373 Jul 17 22:29 cpptest.prg
-rw-r--r--   1 troed  staff  6996 Jul 17 22:29 ctest.prg
-rw-r--r--   1 troed  staff     0 Jul 16 18:13 dummy
-rw-r--r--   1 troed  staff  5296 Jul 17 22:29 lolworld.prg
tmbpr:auto troed$

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 676
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: gcc 7.1 for the ST series

Postby mfro » Mon Jul 24, 2017 6:48 pm

Just tried to build the compiler (Ubuntu 17.04), but didn't succeed.

I had to adapt the mintlib archive filename (it changed from *CVS* something to *Git*) which allowed to build the first stage xgcc, but the second stage gcc build failed afterwards with

Code: Select all

checking for m68k-ataribrowner-elf-gcc...  /home/mfro/Dokumente/Development/bigbrownbuild/build-gcc/./gcc/xgcc -B/home/mfro/Dokumente/Development/bigbrownbuild/build-gcc/./gcc/ -B/usr/m68k-ataribrowner-elf/bin/ -B/usr/m68k-ataribrowner-elf/lib/ -isystem /usr/m68k-ataribrowner-elf/include -isystem /usr/m68k-ataribrowner-elf/sys-include   
checking for C compiler default output file name...
configure: error: in `/home/mfro/Dokumente/Development/bigbrownbuild/build-gcc/m68k-ataribrowner-elf/libbacktrace':
configure: error: C compiler cannot create executables


Not clear what caused this - need to look into it tomorrow.

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: gcc 7.1 for the ST series

Postby troed » Mon Jul 24, 2017 6:52 pm

mfro wrote:configure: error: in `/home/mfro/Dokumente/Development/bigbrownbuild/build-gcc/m68k-ataribrowner-elf/libbacktrace':
configure: error: C compiler cannot create executables


I had the same problem on macOS. If it has anything to do with fortran, just skip it. You can see in the build shellscript that I've done that for macOS.

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Mon Jul 24, 2017 7:04 pm

mfro wrote:Just tried to build the compiler (Ubuntu 17.04), but didn't succeed.

I had to adapt the mintlib archive filename (it changed from *CVS* something to *Git*) which allowed to build the first stage xgcc, but the second stage gcc build failed afterwards with

Code: Select all

checking for m68k-ataribrowner-elf-gcc...  /home/mfro/Dokumente/Development/bigbrownbuild/build-gcc/./gcc/xgcc -B/home/mfro/Dokumente/Development/bigbrownbuild/build-gcc/./gcc/ -B/usr/m68k-ataribrowner-elf/bin/ -B/usr/m68k-ataribrowner-elf/lib/ -isystem /usr/m68k-ataribrowner-elf/include -isystem /usr/m68k-ataribrowner-elf/sys-include   
checking for C compiler default output file name...
configure: error: in `/home/mfro/Dokumente/Development/bigbrownbuild/build-gcc/m68k-ataribrowner-elf/libbacktrace':
configure: error: C compiler cannot create executables


Not clear what caused this - need to look into it tomorrow.


Thanks for trying - I'll get a 17.04 VM running tomorrow and test it myself. One detail though - did you choose to install the compiler in something other than /usr? (I have a suspicion it might be the problem)

Also FWIW, the exact mintlib I used to compile is http://d-bug.mooo.com/releases/mintlib- ... 320.tar.gz
Last edited by ggn on Mon Jul 24, 2017 7:08 pm, edited 1 time in total.
is 73 Falcon patched atari games enough ? ^^

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 676
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: gcc 7.1 for the ST series

Postby mfro » Mon Jul 24, 2017 7:05 pm

ggn wrote:Thanks for trying - I'll get a 17.04 VM running tomorrow and test it myself. One detail though - did you choose to install the compiler in something other than /usr? (I have a suspicion it might be the problem)


No, I'm just fine with /usr (I already have a herd of gcc's there anyway).

User avatar
farvardin
Captain Atari
Captain Atari
Posts: 348
Joined: Fri Jan 01, 2010 5:50 pm
Location: France
Contact:

Re: gcc 7.1 for the ST series

Postby farvardin » Mon Jul 24, 2017 9:13 pm

I had similar problems. I've got the mintlib-Git-20170304 version because the other one was removed from the website. Then I got a bunch of errors (missing folder, which I've created manually). I changed /usr to ~/usr because I didn't want to have mess in my /usr/

Then I got this:

Code: Select all


make[1]: Entering directory `/home/me/github/atari_bigbrownbuild/mintlib-Git-20170304/startup'
m68k-ataribrowner-elf-gcc -Wall -O2 -fomit-frame-pointer -std=gnu89 -fleading-underscore -std=gnu89 -fleading-underscore -fleading-underscore -nostdinc -I../include  -c crt0.S -o crt0.o
crt0.S: Assembler messages:
crt0.S:52: Error: bad expression
crt0.S:52: Error: bad expression
crt0.S:52: Error: operands mismatch -- statement `subl %%a6,%%a6' ignored
/.../
crt0.S:89: Error: invalid operands (*ABS* and *UND* sections) for `%'
make[1]: *** [crt0.o] Error 1
make[1]: Leaving directory `/home/me/github/atari_bigbrownbuild/mintlib-Git-20170304/startup'
make: *** [all-recursive] Error 1


User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Tue Jul 25, 2017 5:30 am

farvardin wrote:I had similar problems. I've got the mintlib-Git-20170304 version because the other one was removed from the website. Then I got a bunch of errors (missing folder, which I've created manually). I changed /usr to ~/usr because I didn't want to have mess in my /usr/

Then I got this:

Code: Select all


make[1]: Entering directory `/home/me/github/atari_bigbrownbuild/mintlib-Git-20170304/startup'
m68k-ataribrowner-elf-gcc -Wall -O2 -fomit-frame-pointer -std=gnu89 -fleading-underscore -std=gnu89 -fleading-underscore -fleading-underscore -nostdinc -I../include  -c crt0.S -o crt0.o
crt0.S: Assembler messages:
crt0.S:52: Error: bad expression
crt0.S:52: Error: bad expression
crt0.S:52: Error: operands mismatch -- statement `subl %%a6,%%a6' ignored
/.../
crt0.S:89: Error: invalid operands (*ABS* and *UND* sections) for `%'
make[1]: *** [crt0.o] Error 1
make[1]: Leaving directory `/home/me/github/atari_bigbrownbuild/mintlib-Git-20170304/startup'
make: *** [all-recursive] Error 1



Can you try again with the mintlib version I linked above?
is 73 Falcon patched atari games enough ? ^^

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Tue Jul 25, 2017 10:01 am

As a follow up: I did set up a ubuntu 17 VM and experienced the same errors as stated above. So I followed troed's suggestion of disabling Fortran and building using the tar.gz version of mintlib I posted above. It all built, so I updated the repository to reflect these changes.

So if anyone can spare an hour or two and try building again it'd be great!
is 73 Falcon patched atari games enough ? ^^

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 676
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: gcc 7.1 for the ST series

Postby mfro » Tue Jul 25, 2017 11:20 am

ggn wrote:As a follow up: I did set up a ubuntu 17 VM and experienced the same errors as stated above. So I followed troed's suggestion of disabling Fortran and building using the tar.gz version of mintlib I posted above. It all built, so I updated the repository to reflect these changes.

So if anyone can spare an hour or two and try building again it'd be great!


Yes. Compiler builds now with your changes.

It also appears to generate executables (after I checked out and compiled the brownout sources as well and copied brown.out to /usr/local/bin), but they crash on Hatari (double bus error).

I tried to look at a disassembly of the executables (using m68k-ataribrowner-elf-objdump -d on the intermediate .elf files). They don't appear to contain startup code and begin with the _exit symbol.
Is this as it's supposed to be?

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Tue Jul 25, 2017 12:04 pm

mfro wrote:
ggn wrote:As a follow up: I did set up a ubuntu 17 VM and experienced the same errors as stated above. So I followed troed's suggestion of disabling Fortran and building using the tar.gz version of mintlib I posted above. It all built, so I updated the repository to reflect these changes.

So if anyone can spare an hour or two and try building again it'd be great!


Yes. Compiler builds now with your changes.

It also appears to generate executables (after I checked out and compiled the brownout sources as well and copied brown.out to /usr/local/bin), but they crash on Hatari (double bus error).

I tried to look at a disassembly of the executables (using m68k-ataribrowner-elf-objdump -d on the intermediate .elf files). They don't appear to contain startup code and begin with the _exit symbol.
Is this as it's supposed to be?


I just tried this and byte compared linux vs windows produced executables side by side - it seems that this is an issue in brownout. Checking....
is 73 Falcon patched atari games enough ? ^^

User avatar
ggn
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 28, 2002 4:49 pm

Re: gcc 7.1 for the ST series

Postby ggn » Tue Jul 25, 2017 12:32 pm

Okay, just pushed a fix for brownout - could you get, recompile and test please?
is 73 Falcon patched atari games enough ? ^^

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 676
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: gcc 7.1 for the ST series

Postby mfro » Tue Jul 25, 2017 4:17 pm

ggn wrote: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?).

Much thanks for your exemplary fast support!


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 2 guests