Project announcement: libcmini

[mfro]

Small notice, the v0.5 release builds here with Ubuntu 14.04LTS and Vincent's gcc build for it:

Code: Select all

$ m68k-atari-mint-gcc --version
m68k-atari-mint-gcc (GCC) 4.6.4 (MiNT 20130415)

That's what it's made for. But it also builds on Windows using Vincent's cygwin cross compiler and on OS X using Philip Donzé's Mac package. Not to forget on the Firebee using the native compiler provided by MiKRO. No excuse anymore to not provide lots of slim software for the ST line .

Nice to see this reached a usable stage.

Thank you. It's still far from complete but certainly useful already.

[wongck]

Thank you. It's still far from complete but certainly useful already.

Yes, it is very useful indeed.
Thank you for making this lib.

[wongck]

Finally got some time today & tested the ACC.
Your build works great.

I copied your code down and compiled on using my own make file, as far as I can see same parameters.
First time I noticed was that my build was 4.8K (m68020-60 & stripped) while yours was 4.4K. All I did was to comment out the RSC header.
Mine, of course, crashed immediately.
I added debug printf but it crashed before any of it wrote out.

[wongck]

Suspected it was the startup.o that was the issue.
So I build acctest.c with -nodefaultlibs and it works.
However, there seems to be some issues with FILE, I guess the gcc startup does something different. (of course)
The FILE function feof() does not seems to return end of file, which makes my ACC runs infinite loop.
(but easily fixed by inspecting the amount read).

Great, now the executable is 80KB less.

[mfro]

Suspected it was the startup.o that was the issue.
So I build acctest.c with -nodefaultlibs and it works.

Umm, yes. You _always_ need to build with -nostdlib and have libcmini's include path first choice (that's why I added my own makefiles to the distribution) and you also need to explicitly link libcmini's startup.o. Otherways you might end up with strange errors since gcc tries to fixup missing bits with mintlib.

However, there seems to be some issues with FILE, I guess the gcc startup does something different. (of course)
The FILE function feof() does not seems to return end of file, which makes my ACC runs infinite loop.
(but easily fixed by inspecting the amount read).

This seems to be something similar. feof() isn't implemented yet in libcmini. If you don't get an undefined symbol error, you are probably pulling stdio.h from the mintlib (instead of libcmini's), mixing up things.

Great, now the executable is 80KB less.

That's the main point. Mission accomplished

[wongck]

When I used -nostdlib I also included startup.o from your source as part of the obj for the build.
I also tried commenting the #ifdef GCRT0, thinking it was the profiler part was an issue.
But it was still failing for me, until I stop using the that startup.o.

Yeah, I looked at your stdio.h and could not find feof(), no wonder it was failing & probably getting it from libc or lgcc as I had it in there.

[wongck]

When I used -nostdlib I also included startup.o from your source as part of the obj for the build.

Ok, so now I see where I gone wrong.
startup.o was not the 1st object..... that's why it was crashing.

[Smonson]

This project looks pretty great! I'd like to try it, but I'm having trouble building it with a linux-hosted cross-compiler and the following options.

Code: Select all

ONLY_68K=Y
BUILD_CF=N
BUILD_FAST=N
MINTLIB_COMPATIBLE=N
COMPILE_ELF=Y
STDIO_WITH_LONG_LONG=N

Code: Select all

$ make
m68k-elf-gcc -MMD -MP -MF objs/abort.d -Wall -Os -fomit-frame-pointer -Iinclude -c sources/abort.c -o objs/abort.o
m68k-elf-gcc -MMD -MP -MF objs/atexit.d -Wall -Os -fomit-frame-pointer -Iinclude -c sources/atexit.c -o objs/atexit.o
sources/atexit.c:7:20: fatal error: memory.h: No such file or directory
 #include <memory.h>
                    ^
compilation terminated.
make: *** [objs/atexit.o] Error 1

Any help would be appreciated!

[simonsunnyboy]

Main issue I can see directly is you are using a generic m68k ELF compiler. You will need one which generates specific binaries for Atari.

You will need m68k-atari-mint-gcc instead of m68k-elf-gcc

You can obtain it from here: http://vincent.riviere.free.fr/soft/m68k-atari-mint/

[Smonson]

Hmm.. interesting. I don't intend to use the C compiler to generate binaries; I have been using vlink. Libcmini's Makefile suggests that a generic gcc is a possible option:

Code: Select all

ifeq (Y,$(COMPILE_ELF))
PREFIX=m68k-elf-
else
PREFIX=m68k-atari-mint-
endif

...I take it then that MiNT' is a dependency of libcmini's build. I'm not really interested in MiNT because I just have a basic ST (hence my interest in this in the first place). I did try making MiNT's headers available to this build process, and it gets further but then dies with assembler errors. I assumed that I was barking up the wrong tree there, but perhaps not. Thanks for the information!

[mfro]

...

Code: Select all

ifeq (Y,$(COMPILE_ELF))
PREFIX=m68k-elf-
else
PREFIX=m68k-atari-mint-
endif

...I take it then that MiNT' is a dependency of libcmini's build.

No, it's not. Binaries should work fine without MiNT. That's libcmini's main purpose: create small footprint binaries for low memory machines with modern gcc.

It requires a recent gcc, however (latest 4.6.4 from Vincent Riviere recommended). This limits available options for the build process: you either need to cross-compile on a PC (this is what I use most often, has been tested using Linux, Windows 7 + cygwin and Mac OS) or compile native on an Atari compatible machine capable to execute the toolchain. This works on the Firebee (tested) and should work on a CT60 as well (not tested). Will require lots of memory and processing power.

I'm not really interested in MiNT because I just have a basic ST (hence my interest in this in the first place). I did try making MiNT's headers available to this build process, and it gets further but then dies with assembler errors. I assumed that I was barking up the wrong tree there, but perhaps not. Thanks for the information!

Post the errors you get and your exact setup and I might be able to help you.

The COMPILE_ELF switch is meant for Armin Diedering's experimental ELF compiler (not generally available). You won't be able to do anything useful with this switch without.

[Smonson]

Thanks mfro. Here's my environment and process:

Code: Select all

$ m68k-elf-gcc --version
m68k-elf-gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ tar zxvf ~/Downloads/libcmini_r_0.5.tar.gz
$ cd libcmini
$ sed -ie "s/m68k-atari-mint/m68k-elf/g" Makefile 
$ make
m68k-elf-gcc -MMD -MP -MF objs/abort.d -Wall -Os -fomit-frame-pointer -Iinclude -c sources/abort.c -o objs/abort.o
m68k-elf-gcc -MMD -MP -MF objs/atexit.d -Wall -Os -fomit-frame-pointer -Iinclude -c sources/atexit.c -o objs/atexit.o
sources/atexit.c:7:20: fatal error: memory.h: No such file or directory
 #include <memory.h>
                    ^
compilation terminated.
make: *** [objs/atexit.o] Error 1

I'm comfortable with cross-compilers, so I saw no reason to install the special MiNT one. I'm expecting you to say "go and install the special MiNT one!" next.

[mfro]

...
I'm comfortable with cross-compilers, so I saw no reason to install the special MiNT one. I'm expecting you to say "go and install the special MiNT one!" next.

Yes, exactly .

You don't need MiNT, you don't need mintlib, but you'll need the m68k-atari-mint toolchain that will be able to generate Atari-compatible binary files.

[Smonson]

Hmm, gcc-atari-mint isn't supported for my Ubuntu machine and I'm not really interested in changing my OS just for this. But looking further, these include files (memory.h is just the first of many) are mintlib headers that must be present for the libcmini build. The reason why it failed with mintlib's include files present before is that they use a non-GNU assembly syntax (no % signs on register names) which must be one of the customisations done in the customised atari-mint binutils/gcc package.

Changing that syntax seems like a matter of the maintainer's personal preference, and it needlessly ties mintlib to the custom toolchain, so I can't compile it with gcc. This is annoying. And since libcmini has a hard dependency on mintlib, unfortunately there's no way I can use it without a large buy-in. For now I'll write a libc as I go along.

I have to congratulate you on the project, as it looks extremely impressive. Thank you for the assistance even if I'm too stubborn to get a result

[mfro]

Hmm, gcc-atari-mint isn't supported for my Ubuntu machine

Wrong. Yes, it's not in the official repositories, but why don't you just add

Code: Select all

deb http://vincent.riviere.free.fr/debian/ wily contrib

to your /etc/apt/sources.list and do a sudo apt install cross-mint-essential?

and I'm not really interested in changing my OS just for this. But looking further, these include files (memory.h is just the first of many) are mintlib headers that must be present for the libcmini build. The reason why it failed with mintlib's include files present before is that they use a non-GNU assembly syntax (no % signs on register names) which must be one of the customisations done in the customised atari-mint binutils/gcc package.

Wrong as well. All gnu assemblers for 68k support the --register-prefix-optional command line switch which allows exactly that. It's just that it's the default for m68k-atari-mint-as while its not for m68k-elf-as. This doesn't have anything to do with mintlib.

Changing that syntax seems like a matter of the maintainer's personal preference, and it needlessly ties mintlib to the custom toolchain, so I can't compile it with gcc. This is annoying. And since libcmini has a hard dependency on mintlib, unfortunately there's no way I can use it without a large buy-in. For now I'll write a libc as I go along.

Yes. Libcmini cannibalizes some of the mintlib include files. Without pulling anything from the lib. That's its intended purpose, basically.

I probably just don't really understand your problem. m68k-atari-mint-gcc _is_ gcc. You won't be able to generate Atari compatible relocatable binary files with anything else. You might be able to create a libc based on m68k-elf, but how would you execute that on an Atari? I really miss your point here, frankly.

I have to congratulate you on the project, as it looks extremely impressive. Thank you for the assistance even if I'm too stubborn to get a result

Thanks anyway. I'm still not convinced you are on the right path, honestly .

[Smonson]

Yes, it's not in the official repositories, but why don't you just add

Code: Select all

deb http://vincent.riviere.free.fr/debian/ wily contrib

to your /etc/apt/sources.list and do a sudo apt install cross-mint-essential?

Because I'm not running Wily.

Wrong as well. All gnu assemblers for 68k support the --register-prefix-optional command line switch which allows exactly that.

This is excellent, I never knew about this switch. Thanks - I think this will solve the problem

m68k-atari-mint-gcc _is_ gcc. You won't be able to generate Atari compatible relocatable binary files with anything else. You might be able to create a libc based on m68k-elf, but how would you execute that on an Atari? I really miss your point here, frankly.

As I already said I'm using vlink, although later I'll probably try to find something better. The TOS format is extremely simple - to write a converter would be a quick job. I'd be interested to know what the difference is between m68k-linux-mint gcc and the native m68k-elf one. Obviously binutils is going to be modified, but gcc itself... no need. I have been running binaries all weekend with the standard distro.

[simonsunnyboy]

Yes, it's not in the official repositories, but why don't you just add

Code: Select all

deb http://vincent.riviere.free.fr/debian/ wily contrib

to your /etc/apt/sources.list and do a sudo apt install cross-mint-essential?

Because I'm not running Wily.

IIRC Vincent has the gcc for all reasonable modern flavours of Ubuntu. I personally have the 14.04 binaries installed:

Code: Select all

deb http://vincent.riviere.free.fr/debian/ trusty contrib
deb-src http://vincent.riviere.free.fr/debian/ trusty contrib

If all fails, Mikro has a makefile to compile the Atari toolchain from gnu.org downloads. Vincent links to it from his website.

[Smonson]

Because I'm not running Wily.

IIRC Vincent has the gcc for all reasonable modern flavorus of Ubuntu.

I see. I didn't know that. I went to the download page and it says in a bold heading across the top:

The only supported version is Ubuntu 15.10 "Wily Werewolf" (both 32-bit and 64-bit).

...so I stopped.

If all fails, Mikro has a makefile to compile the Atari toolchain from gnu.org downloads. Vincent links to it from his website.

You mean the one built to run under MiNT itself? I think that's a little more 'retro' than I'm looking for at the moment

[simonsunnyboy]

Well, it can be crosscompiled to run on MinT itself but as far as I understood Mikro's Makefile, it should be able to build a Linux/PC hosted cross toolchain too. Maybe he can help you? He is a user on this forum too.

[mfro]

As I already said I'm using vlink,

Must have missed that, sorry.

although later I'll probably try to find something better. The TOS format is extremely simple - to write a converter would be a quick job. I'd be interested to know what the difference is between m68k-linux-mint gcc and the native m68k-elf one. Obviously binutils is going to be modified, but gcc itself... no need. I have been running binaries all weekend with the standard distro.

All the patches are available at Vincent's site if you want to know what's different.

For what's worth, I still not understand why somebody would throw together a toolchain like this instead of using the proven quasi-standard? Just because of not willing to use the latest Ubuntu?

[Smonson]

I still not understand why somebody would throw together a toolchain like this instead of using the proven quasi-standard?

100% agreed. I didn't come here to get into an argument over who has the best compiler, just to discover information that would allow me to use the libcmini project.

I looked into the changes last night that Vincent made in the atari-mint gcc fork. They are very minor and done with a good justification. For the benefit of posterity, the pertinent ones here are:

• enabling the --register-prefix-optional setting by default in order to allow gcc to compile legacy assembler programs
• enabling an internal gcc setting to place an underscore prefix on local assembler labels

On the first point, --register-prefix-optional is tolerated by the gcc devs but it is clear they would rather get rid of it and let people rewrite their code that relies on this trouble-prone behaviour - see here for detail: https://sourceware.org/ml/binutils/2007 ... 00336.html.

To the second, this appends an underscore to labels in gcc's assembler output in order to differentiate them from register names, solving the inherent ambiguity of labels vs registers that is introduced by using --register-prefix-optional in the first place. I don't think there's any switch that can turn this behaviour on.

The rest of the changes are just setting defaults etc.

I don't think you'll be the slightest bit interested, but a small patch to allow mintlib to build under a non-customised m86k cross-gcc is here: http://smonson.com/unmanaged/atari/libc ... 5-gcc.diff (however it doesn't fix the tests, as they have totally separate Makefiles).

Thanks again for your work and information provided here

[mfro]

Must have missed your answer, just found it by accident.

I don't think you'll be the slightest bit interested, but a small patch to allow mintlib to build under a non-customised m86k cross-gcc is here: http://smonson.com/unmanaged/atari/libc ... 5-gcc.diff (however it doesn't fix the tests, as they have totally separate Makefiles).

I actually do.

The a.out binary format m68k-atari-mint-gcc is based on is dead.

Your approach might be a good (and the only) way to bring gcc on the Atari platform to recent (ELF-based) versions.

[BlankVector]

I see. I didn't know that. I went to the download page and it says in a bold heading across the top:

The only supported version is Ubuntu 15.10 "Wily Werewolf" (both 32-bit and 64-bit).

...so I stopped.

It is what I say, but not what I do.
I keep binaries for older Ubuntu in my repository, even if I don't update them. Just follow the documentation, by replacing the name of newest distribution with the older.
Note that I still remove the binaries when the Ubuntu distribution itself expires.

[mfro]

With AtariForge down since weeks, I decided to move libcmini to a more reliable host. It found its new home at github: https://github.com/mfro0/libcmini

[wongck]

Thank you for the excellent small lib.
Sorry for my lack of knowledge on Github, but these are sources and there is no ready to use Lib.
Is that true or am I looking at the wrong place?