freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Getting slattach to work

[David H. <dh...@ai...>]

Hi Miro,

I’ve submitted a pull request which I have tested on real hardware and Hatari. It’s not quite the absolute bare minimum necessary as I introduced a #define for the O_GLOBAL bit pattern, but it’s hopefully minimal enough to not cause side effects.

https://github.com/freemint/freemint/pull/437

Fingers crossed for your vcons work :)

Regards,

-- 
David.


> On 18 Jan 2026, at 02:32, Miro Kropáček <mir...@gm...> wrote:
> 
> Thank you for the report and nice screenshot. :) Looking forward to the final patch! (please include there also the /sbin change, I don't think we are going to use /sbin again. There was a similar issue with ping from sparemint: https://github.com/freemint/freemint/issues/372#issuecomment-3686971149 so it makes sense to have ping and slattach use the same hardcoded folder (/bin).
> 
> Btw, I have actually investigated the vcons issue to some extent: https://github.com/freemint/freemint/issues/118 ... but fixing it requires taking a deep breath and start digging into the most hardcore freemint internals (or not, who knows ;)). 
> 

Re: [Freemint-discuss] Getting slattach to work

[Miro K. <mir...@gm...>]

Thank you for the report and nice screenshot. :) Looking forward to the
final patch! (please include there also the /sbin change, I don't think we
are going to use /sbin again. There was a similar issue with ping from
sparemint:
https://github.com/freemint/freemint/issues/372#issuecomment-3686971149 so
it makes sense to have ping and slattach use the same hardcoded folder
(/bin).

Btw, I have actually investigated the vcons issue to some extent:
https://github.com/freemint/freemint/issues/118 ... but fixing it
requires taking a deep breath and start digging into the most hardcore
freemint internals (or not, who knows ;)).

On Sat, 17 Jan 2026 at 10:06, David Henderson via Freemint-discuss <
fre...@li...> wrote:

> Hi Miro,
>
> Success! I’ve just read your email on a telnet session from my Falcon
> connected over SLIP.
>
> Many thanks for the pointers. I’ll try to reduce my changes to the minimum
> needed next week and report back.
>
> I actually had an older version of slattach on my Falcon (presumably from
> Sparemint which is the basis of this machine) which interestingly had less
> opaque error messages, but both my recently compiled one and that old one
> (dated 2013) worked well with the modified kernel and slip.xif.
>
> This takes me back to my college days of using KGMD and slattach to my
> linux PC to get my Falcon on the internet full time. It was all virtual
> consoles and no GEM for me back then. The bootable Freemint installation is
> certainly a much nicer experience. Thank you all for that. Although I do
> kind of miss the snappiness of IRC on F1 and PINE on F2 :-)
>
> David.
>
>
>
>
>
> > On 16 Jan 2026, at 22:11, Miro Kropáček <mir...@gm...> wrote:
> >
> > Thanks for not giving up, David! :-)
> >
> > One thing to try, especially for verifying the Hatari setup could be
> downloading some older version of freemint and run its slattach.
> >
> > I remember fixing one pointer bug in there back in the 2000s so it must
> have worked at some point before O_GLOBAL removal.
> >
> > http://mikro.atari.org
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

Re: [Freemint-discuss] Getting slattach to work

[David H. <dh...@ai...>]

Hi Miro,

Success! I’ve just read your email on a telnet session from my Falcon connected over SLIP.

Many thanks for the pointers. I’ll try to reduce my changes to the minimum needed next week and report back.

I actually had an older version of slattach on my Falcon (presumably from Sparemint which is the basis of this machine) which interestingly had less opaque error messages, but both my recently compiled one and that old one (dated 2013) worked well with the modified kernel and slip.xif.

This takes me back to my college days of using KGMD and slattach to my linux PC to get my Falcon on the internet full time. It was all virtual consoles and no GEM for me back then. The bootable Freemint installation is certainly a much nicer experience. Thank you all for that. Although I do kind of miss the snappiness of IRC on F1 and PINE on F2 :-)

David.

Re: [Freemint-discuss] Getting slattach to work

[Miro K. <mir...@gm...>]

Thanks for not giving up, David! :-)

One thing to try, especially for verifying the Hatari setup could be
downloading some older version of freemint and run its slattach.

I remember fixing one pointer bug in there back in the 2000s so it must
have worked at some point before O_GLOBAL removal.

http://mikro.atari.org

On Sat, 17 Jan 2026, 12:21 am David Henderson via Freemint-discuss, <
fre...@li...> wrote:

> Thanks Miro,
>
> Progress!
>
> The negative check continues to failing (reading 0x8000 as -32768), but
> that feels more like a real file descriptor (0 + offset) than the -38 it
> was returning before.
>
> So, removing both the kernel device name check and the negative return on
> f_open(), I was faced with the same ‘cannot make tty raw’ error which comes
> from this:
> https://github.com/freemint/freemint/blob/master/sys/sockets/xif/serial.c#L314
>
> I can’t find much information about that, but on the off-chance I tried
> giving the slattach call different devices to play with and discovered that
> /dev/ttyS1 (instead of /dev/modem2 — I thought they were aliases) works!
>
> I say works — output is being generated in the Hatari serial output file
> as packets count up — but I’ll need to test it on proper hardware later.
> So… maybe?
>
> It feels like the slip.xif, whilst building, may be using some old
> interpretations of the kernel interface. What’s the correct way to test for
> failure of that f_open() call? I note the returned value ‘fd' is stored as
> a short (and remains so in the slip interface structure), but the function
> wrapped declares a long return. Is it as simple as that?
>
> Thanks,
>
> David.
>
> PS. FWIW, slattach.c defines _PATH_IFCONFIG in /sbin. The bootable
> snapshots have it in /bin
>
>
> > On 16 Jan 2026, at 11:56, Miro Kropáček <mir...@gm...> wrote:
>
> > f_open is a pointer to the kernel lookup table, leading to... here:
> https://github.com/freemint/freemint/blob/af8c03db1a94e41025f4f217296cce26f5e8b03c/sys/dosfile.c#L46.
> As you can see, that's exactly the root of all evil.
> >
> > Since you seem to be fluent in changing code and compiling it, try to
> remove that check for "name" and see what happens.
> >
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

Re: [Freemint-discuss] Getting slattach to work

[David H. <dh...@ai...>]

Thanks Miro,

Progress!

The negative check continues to failing (reading 0x8000 as -32768), but that feels more like a real file descriptor (0 + offset) than the -38 it was returning before.

So, removing both the kernel device name check and the negative return on f_open(), I was faced with the same ‘cannot make tty raw’ error which comes from this: https://github.com/freemint/freemint/blob/master/sys/sockets/xif/serial.c#L314

I can’t find much information about that, but on the off-chance I tried giving the slattach call different devices to play with and discovered that /dev/ttyS1 (instead of /dev/modem2 — I thought they were aliases) works!

I say works — output is being generated in the Hatari serial output file as packets count up — but I’ll need to test it on proper hardware later. So… maybe?

It feels like the slip.xif, whilst building, may be using some old interpretations of the kernel interface. What’s the correct way to test for failure of that f_open() call? I note the returned value ‘fd' is stored as a short (and remains so in the slip interface structure), but the function wrapped declares a long return. Is it as simple as that?

Thanks,

David.

PS. FWIW, slattach.c defines _PATH_IFCONFIG in /sbin. The bootable snapshots have it in /bin


> On 16 Jan 2026, at 11:56, Miro Kropáček <mir...@gm...> wrote:

> f_open is a pointer to the kernel lookup table, leading to... here: https://github.com/freemint/freemint/blob/af8c03db1a94e41025f4f217296cce26f5e8b03c/sys/dosfile.c#L46. As you can see, that's exactly the root of all evil.
> 
> Since you seem to be fluent in changing code and compiling it, try to remove that check for "name" and see what happens. 
> 

Re: [Freemint-discuss] Getting slattach to work

[Miro K. <mir...@gm...>]

On Fri, 16 Jan 2026 at 21:14, David Henderson via Freemint-discuss <
fre...@li...> wrote:

> In my case /dev/modem2
>
Then it's clear, it's the problem I mentioned in the last email.

I don’t know where to find docs for f_open()
>
f_open is a pointer to the kernel lookup table, leading to... here:
https://github.com/freemint/freemint/blob/af8c03db1a94e41025f4f217296cce26f5e8b03c/sys/dosfile.c#L46.
As you can see, that's exactly the root of all evil.

Since you seem to be fluent in changing code and compiling it, try to
remove that check for "name" and see what happens.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Getting slattach to work

[David H. <dh...@ai...>]

Hi Miro,

The device being opened is the serial device specified with -t on the command line. In my case /dev/modem2, for example, or the PTS if working with STDIN.

I did actually try passing it /dev/console to see if the behaviour changed, but it doesn’t.

I did notice the call is to f_open() rather than fopen() or Fopen(), so I’m not sure what return value is expected, but the program is testing for a negative value being an error.

I recall your suggestion to use an 0x8000 offset for global handles a while back. I don’t know if that’s what happened in the end, but could this be valid handle interpreted as an error?

Just in case I changed the error detection (here https://github.com/freemint/freemint/blob/master/sys/sockets/xif/serial.c#L388 ) to test for null (again, I don’t know if that’s right, I don’t know where to find docs for f_open(), but I figured I’d try it) and then the error turns into ‘cannot make tty raw’.

I’ll investigate where that comes from next, but I’m not really sure what I’m doing and would appreciate some pointers if anyone’s a bit more au fait with such things, please.

Cheers,

-- 
David



> On 15 Jan 2026, at 22:54, Miro Kropáček <mir...@gm...> wrote:
> 
> Hi David,
> 
> On Fri, 16 Jan 2026 at 04:41, David Henderson via Freemint-discuss <fre...@li...> wrote:
> Our old friend O_GLOBAL features here:
> 
> https://github.com/freemint/freemint/blob/master/sys/sockets/xif/serial.c#L387
> 
> Which ties it more directly to the work at hand, but fails to hand me a eureka moment, I'm afraid, so the plea for help stands.
> What device does it try to open? You can put a debug output either into serial.c or enable TRACE level in the freemint kernel (when compiled as a debug build).
> 
> My first guess would be that it doesn't open neither "u:\dev\console" nor "u:\pipe\sld" and therefore fails. My initial understanding was that those are the only devices which are using the O_GLOBAL path. Perhaps I was wrong and the check has to be reworked/removed.
> 
> -- 
> http://mikro.atari.org
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Getting slattach to work

[Miro K. <mir...@gm...>]

Hi David,

On Fri, 16 Jan 2026 at 04:41, David Henderson via Freemint-discuss <
fre...@li...> wrote:

> Our old friend O_GLOBAL features here:
>
>
> https://github.com/freemint/freemint/blob/master/sys/sockets/xif/serial.c#L387
>
> Which ties it more directly to the work at hand, but fails to hand me a
> eureka moment, I'm afraid, so the plea for help stands.
>
What device does it try to open? You can put a debug output either into
serial.c or enable TRACE level in the freemint kernel (when compiled as a
debug build).

My first guess would be that it doesn't open neither "u:\dev\console" nor
"u:\pipe\sld" and therefore fails. My initial understanding was that those
are the only devices which are using the O_GLOBAL path. Perhaps I was wrong
and the check has to be reworked/removed.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Getting slattach to work

[David H. <dh...@ai...>]

On Thu, 15 Jan 2026, David Henderson via Freemint-discuss wrote:

> I've traced this further to slip.xif and building it with debug (a few printf() parameter fixes are required) shows 'no free serial channels' is the real error:
> 

Apologies, I realised about five minutes after sending that that the error I quoted doesn't match that line (no free *slip* channels).

The 'no free serial channels' error is a result of f_open() failing in serial.c. Our old friend O_GLOBAL features here:

https://github.com/freemint/freemint/blob/master/sys/sockets/xif/serial.c#L387

Which ties it more directly to the work at hand, but fails to hand me a eureka moment, I'm afraid, so the plea for help stands.

David (BW)

Re: [Freemint-discuss] Getting slattach to work

On Thu, 15 Jan 2026, David Henderson via Freemint-discuss wrote:

> I've traced this further to slip.xif and building it with debug (a few 
> printf() parameter fixes are required) shows 'no free serial channels' is the 
> real error:
>

Apologies, I realised about five minutes after sending that that the error 
I quoted doesn't match that line (no free *slip* channels).

The 'no free serial channels' error is a result of f_open() failing in 
serial.c. Our old friend O_GLOBAL features here:

https://github.com/freemint/freemint/blob/master/sys/sockets/xif/serial.c#L387

Which ties it more directly to the work at hand, but fails to hand me a 
eureka moment, I'm afraid, so the plea for help stands.

David (BW)

[Freemint-discuss] Getting slattach to work

[David H. <dh...@ai...>]

Good afternoon all,

Following on from Miro's work on O_GLOBAL and the reintroduction of 
slip.xif last year...

https://sourceforge.net/p/freemint/mailman/message/58848145/

https://github.com/freemint/freemint/pull/379

...I'm keen to start using SLIP (via slattach) again.

I keep running into a 'Cannot allocate memory' error when trying to use 
slattach to create an interface from /dev/modem2 (or whatever serial port 
I've active). This started out on real hardware, but has moved onto Hatari 
for debugging, although I get the same result if omitting the port (having 
it try to attach to stdin).

I'm emulating a falcon with --scc-b-in and --scc-b-out set on the command 
line and inet4.xdd, scc.xdd and slip.xif in the mint directory.

I've build the latest slattach source myself and have found the error 
comes from an ioctl() SIOCSIFLINK call:

https://github.com/freemint/freemint/blob/master/tools/net-tools/slattach.c#L144

I've traced this further to slip.xif and building it with debug (a few 
printf() parameter fixes are required) shows 'no free serial channels' is 
the real error:

https://github.com/freemint/freemint/blob/master/sys/sockets/xif/slip.c#L110

Looking at slip_priv[].flags and SLF_LINKED, I can't see a glaring issue, 
so at this point I'll have to ask for a lifeline as I was somewhat out of 
my depth about three paragraphs back.

Can anyone help me restore slattach (and iflink, FWIW) to a usable state?

Thanks,

David (badwolf).

Re: [Freemint-discuss] is fremont usable with 4 Mb of ram?

[Jo E. S. <jo...@on...>]

On Thu, 18 Dec 2025 14:53:43 +1000, "Miro Kropáček" <mir...@gm...> wrote:

>> ST MiNT: https://subsole.org/st_mint is definitely the best way to start.
>>
>> As for a C compiler, gcc is out of question and the classic ones (Pure-C
>> etc) are usually not very happy when running in MiNT.

PureC is very happy with MiNT. I have been using PureC for thousands of hours under MiNT the last 30 years. The source level debugger is not really usable though. There's patches and tricks to get it running, but IMO it's very unstable.

But generally speaking - with only 4Mb RAM there is little use in MiNT. I would look into MagiC instead.

Jo Even

Re: [Freemint-discuss] is fremont usable with 4 Mb of ram?

[Miro K. <mir...@gm...>]

ST MiNT: https://subsole.org/st_mint is definitely the best way to start.

As for a C compiler, gcc is out of question and the classic ones (Pure-C
etc) are usually not very happy when running in MiNT.

On Thu, 18 Dec 2025 at 14:29, ROBERT MYERS via Freemint-discuss <
fre...@li...> wrote:

> I’d like to know if FreeMINT is usable with $ Mb of ram.  Does it include
> a C compiler for use?
> I ask this since there isn’t an available source for alt-ram at this time.
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] is fremont usable with 4 Mb of ram?

[ROBERT M. <rj...@ya...>]

I’d like to know if FreeMINT is usable with $ Mb of ram.  Does it include a C compiler for use?
I ask this since there isn’t an available source for alt-ram at this time.

Re: [Freemint-discuss] pkgsrc: issues with bootstrap on FreeMiNT

[Miro K. <mir...@gm...>]

On Thu, 18 Dec 2025 at 07:16, Xavier via Freemint-discuss <
fre...@li...> wrote:

> The first concerns the default value of umask. It's 0022 on Unix, but
> 0000 on FreeMiNT. Is this to ensure maximum compatibility with legacy
> TOS applications? Or would it be possible to set it to 0022 without
> impacting these applications (which theoretically shouldn't depend on
> permissions for groups and other users)? Bootstrap requires this minimum
> value of 0022, as do some other packages (workaround: simply run umask
> 0022 before running bootstrap or bmake).
>
I wanted to suggest the same, putting 'umask 022' into /etc/profile so it's
read by the shell as the first thing. As for the initial value, I don't
know. The zero has been there since at least MiNT 1.12.

Second question: realpath returns paths without symlinks, such as
> /c/usr/pkg because /usr is a link to u:/c/usr. Can this be fixed by
> removing the first two characters (in the case of disk drives, not for
> other filesystems like /kern or /shm) without disrupting internal kernel
> functions?
>
Wouldn't this defy the purpose of realpath? Imagine that I'm interested to
know where /usr points to. So I read the documentation and learn that
realpath() is the way to go. And it wouldn't work.

Last question (for now): diff, sed, and wc crash very often. For diff,
> simply running `diff -u file1.txt file2.txt` causes a crash. This seems
> related to the handling of multi-byte characters. Are you aware of any
> programs to test the corresponding functions, such as mbrtowc or iswspace?

Do older tools from SpareMiNT also crash? Could be a bug in more recent
mintlib versions.

-- 
http://mikro.atari.org

[Freemint-discuss] pkgsrc: issues with bootstrap on FreeMiNT

[Xavier <x.d...@la...>]

Last month, I ported the core pkgsrc tools from NetBSD (bmake, 
pkg_install, libnbcompat, bootstrap-mk-files, and digest, as well as 
libarchive, fetch, and libfetch), but their proper functioning isn't 
guaranteed, and I encountered many difficulties completing the bootstrap.

So, I have several questions.

The first concerns the default value of umask. It's 0022 on Unix, but 
0000 on FreeMiNT. Is this to ensure maximum compatibility with legacy 
TOS applications? Or would it be possible to set it to 0022 without 
impacting these applications (which theoretically shouldn't depend on 
permissions for groups and other users)? Bootstrap requires this minimum 
value of 0022, as do some other packages (workaround: simply run umask 
0022 before running bootstrap or bmake).

Second question: realpath returns paths without symlinks, such as 
/c/usr/pkg because /usr is a link to u:/c/usr. Can this be fixed by 
removing the first two characters (in the case of disk drives, not for 
other filesystems like /kern or /shm) without disrupting internal kernel 
functions?

Last question (for now): diff, sed, and wc crash very often. For diff, 
simply running `diff -u file1.txt file2.txt` causes a crash. This seems 
related to the handling of multi-byte characters. Are you aware of any 
programs to test the corresponding functions, such as mbrtowc or iswspace?

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Miro K. <mir...@gm...>]

On Tue, 2 Dec 2025 at 01:32, Daroou via Freemint-discuss <
fre...@li...> wrote:

> I was expecting at least a slight gain with LIBCmini ELF, but it's the
> opposite: the target sizes increase by 5KB...

Don't forget that you are using a different compiler (often a new version =
bigger produced code, EmuTOS uses 4.6.4, too).

I see that your LIBCmini ELF is quite large:
>
> LIBCmini 4.6.4    96.832
>
> LIBCmini ELF     203.428
>
> Does this affect the program size?
>
You have seen it for yourself, it doesn't. My guess is that ELF format
produces more symbols. You can verify that by calling

m68k-atari-mint(elf)-strip -s libc.a

After that you can't link the library again but you will see its raw size.

I'll continue using GCC 4.6.4... However, GCC 13.2.0 ELF allowed me to fix
> many errors and warnings in my code.
>
One good practice, again from EmuTOS: compile your code with the latest ELF
compiler but release binaries with your 4.6.4 => you will get the best of
both worlds.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Daroou <da...@fr...>]

Le 01/12/2025 à 00:52, Miro Kropáček a écrit :
> On Mon, 1 Dec 2025 at 01:04, Daroou via Freemint-discuss 
> <fre...@li...> wrote:
>
>     [/cygdrive/e/cygwin64/opt/cross-mintelf/m68k-atari-mintelf/libcmini/lib/crt0.o:
>
>     file not recognized: file format not recognized
>     collect2: error: ld returned 1 exit status ]
>
> Hmm, not sure where this comes from. It looks like using old binutils 
> (which do not know about the ELF format?)

This error is normal because it's a copy of LIBCmini for GCC 'standard' 
(not ELF).


(I can't compile LIBCmini in ELF format; however, EmuTOS compiles 
perfectly in ELF format.)


> However I have built http://naprvyraz.sk/private/libcmini.tar.gz for 
> you, if you prefer this way. _stksize can be modified with 
> m68k-atari-mintelf-stack --fix=<amount>k command.

Ďakujem Miro :)


I didn't have to change anything; _stksize is set to 64KB.


However, I'm a little disappointed. Given the size reduction with the 
MINTlib targets (-30KB),

I was expecting at least a slight gain with LIBCmini ELF, but it's the 
opposite: the target

sizes increase by 5KB...


                m68k-atari-mint-gcc  m68k-atari-mintelf-gcc
MINTlib  68k         263.988                 235.923
MINTlib  206         244.519                 217.028

LIBCmini 68K          99.134                 104.022
LIBCmini 206          90.999                  95.847


RAM 1Mo              192.940 free            189.856 free


I see that your LIBCmini ELF is quite large:

LIBCmini 4.6.4    96.832

LIBCmini ELF     203.428

Does this affect the program size?


I'll continue using GCC 4.6.4... However, GCC 13.2.0 ELF allowed me to 
fix many errors and warnings in my code.


  Have a good day, Thank you for your help.

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Miro K. <mir...@gm...>]

On Mon, 1 Dec 2025 at 01:04, Daroou via Freemint-discuss <
fre...@li...> wrote:

> [/cygdrive/e/cygwin64/opt/cross-mintelf/m68k-atari-mintelf/libcmini/lib/crt0.o:
>
> file not recognized: file format not recognized
> collect2: error: ld returned 1 exit status ]
>
Hmm, not sure where this comes from. It looks like using old binutils
(which do not know about the ELF format?)

Is it possible to find LIBCmini ELF format with
> _stksize==MINKEEP somewhere? ;-)
>
Not sure which OS are you using but if it's WSL2 or Linux, you can try:
https://github.com/mikrosk/m68k-atari-mint-build and
https://github.com/mikrosk/build-scripts. This will install you latest gcc,
binutils, mintlib, libcmini and a few other libs I'm using regularly.

However I have built http://naprvyraz.sk/private/libcmini.tar.gz for you,
if you prefer this way. _stksize can be modified with
m68k-atari-mintelf-stack --fix=<amount>k command.


> Soon, but not on daroou.fr; I no longer own that domain.

Great!

-- 
http://mikro.atari.org

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Daroou <da...@fr...>]

Hello Miro,


Le 30/11/2025 à 10:15, Miro Kropáček a écrit :
> I tried to reproduce your problem on my m68-atari-mintelf-gcc 13.4.0 
> and all worked fine (I even edited the Makefile as per your example). 
> Do you have mintlib installed? It's a bit counter intuitive but 
> libcmini requires mintlib for some of its parts. I suspect 
> that isblank might be one of such examples.

Ok, so the problem is on my side.


For info, I'm a novice; I don't understand much about Makefiles or other ;)

In the Makefile, I only change the options to Y or N.  I can only 
compile LIBCmini for GCC 4.6.4.


Currently, I can compile my programs with GCC 4.6.4 or with GCC ELF 
13.2.0 with MintLIB, and only with GCC 4.6.4 with LIBCmini.


Example for Boing -m68000:

GCC 4.6.4 MintLIB 263.803

GCC 4.6.4 LIBCmini 99.006

GCC ELF 13.2.0 MintLIB 235.767

GCC ELF 13.2.0 LIBCmini: need LIBCmini ELF format

[/cygdrive/e/cygwin64/opt/cross-mintelf/m68k-atari-mintelf/libcmini/lib/crt0.o: 
file not recognized: file format not recognized
collect2: error: ld returned 1 exit status ]


Is it possible to find LIBCmini ELF format with _stksize==MINKEEP 
somewhere? ;-)

(It's going to be too hard to figure out why it's not compiling, I think.)


[...]

> P.S. Hope to see http://atari.daroou.fr online again soon! :-)
>
Soon, but not on daroou.fr; I no longer own that domain.


P.S.: Sorry for the poor web translation ;)

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Miro K. <mir...@gm...>]

Hi,

I tried to reproduce your problem on my m68-atari-mintelf-gcc 13.4.0 and
all worked fine (I even edited the Makefile as per your example). Do you
have mintlib installed? It's a bit counter intuitive but libcmini requires
mintlib for some of its parts. I suspect that isblank might be one of such
examples.

P.S. Hope to see http://atari.daroou.fr online again soon! :-)

On Sat, 29 Nov 2025 at 06:17, Daroou via Freemint-discuss <
fre...@li...> wrote:

> Bonjour,
>
>
> I'm currently testing Vincent Rivière's m68k-atari-mintelf cross-tools
> (under cygwin)
>
> 'Hello world' compiles perfectly with Mintlib.
>
> However, I want to use LIBCmini for my programs.
>
> https://github.com/freemint/libcmini
>
> GCC ELF refuses to compile LIBCmini because of this error:
>
> [Makefile]
>
> ONLY_68K=Y
> BUILD_CF=N
> BUILD_FAST=N
> BUILD_SOFT_FLOAT=Y
> BUILD_SHORT=Y
> COMPILE_ELF=Y
> STDIO_WITH_LONG_LONG=N
>
>
> $ m68k-atari-mintelf-gcc --version
>
> m68k-atari-mintelf-gcc (GCC MiNT ELF 20240130) 13.2.0
> Copyright (C) 2023 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.
>
> make clean
>
> make libs
>
> CC build/./objs/isblank.o
> sources/isblank.c: In function 'isblank':
> sources/isblank.c:4:6: error: infinite recursion detected
> [-Werror=infinite-recursion]
>      4 | int (isblank)(int c)
>        |      ^~~~~~~
> sources/isblank.c:6:16: note: recursive call
>      6 |         return isblank(c);
>        |                ^~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [Makefile:162: build/./objs/isblank.o] Error 1
>
>
> [isblank.c]
>
> #include <ctype.h>
> #include "ctypeint.h"
>
> int (isblank)(int c)
> {
>      return isblank(c);
> }
> [/isblank.c]
>
>
>
>
> Compiles perfectly with standard GCC
>
> [Makefile]
>
> ONLY_68K=Y
> BUILD_CF=N
> BUILD_FAST=N
> BUILD_SOFT_FLOAT=Y
> BUILD_SHORT=Y
> COMPILE_ELF=N
> STDIO_WITH_LONG_LONG=N
>
>
> $ m68k-atari-mint-gcc --version
>
> m68k-atari-mint-gcc (GCC) 4.6.4 (MiNT 20200504)
> Copyright (C) 2011 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.
>
> make clean
>
> make libs
>
> [...]
>
> CC build/./objs/setstack.o
> AR build/./libcmini.a
> CC build/./objs/iio/doprnt.o
> AR build/./libiiomini.a
>
> make clean
>
> make all
>
> [...]
>
> CC build/./objs/setstack.o
> AR build/./libcmini.a
> CC build/./objs/iio/doprnt.o
> AR build/./libiiomini.a
> CC build/crt0.o
> CC build/minicrt0.o
>
>
> Thank you for your help.
>
> Merci.
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Daroou <da...@fr...>]

Bonjour,


I'm currently testing Vincent Rivière's m68k-atari-mintelf cross-tools 
(under cygwin)

'Hello world' compiles perfectly with Mintlib.

However, I want to use LIBCmini for my programs.

https://github.com/freemint/libcmini

GCC ELF refuses to compile LIBCmini because of this error:

[Makefile]

ONLY_68K=Y
BUILD_CF=N
BUILD_FAST=N
BUILD_SOFT_FLOAT=Y
BUILD_SHORT=Y
COMPILE_ELF=Y
STDIO_WITH_LONG_LONG=N


$ m68k-atari-mintelf-gcc --version

m68k-atari-mintelf-gcc (GCC MiNT ELF 20240130) 13.2.0
Copyright (C) 2023 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.

make clean

make libs

CC build/./objs/isblank.o
sources/isblank.c: In function 'isblank':
sources/isblank.c:4:6: error: infinite recursion detected 
[-Werror=infinite-recursion]
     4 | int (isblank)(int c)
       |      ^~~~~~~
sources/isblank.c:6:16: note: recursive call
     6 |         return isblank(c);
       |                ^~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:162: build/./objs/isblank.o] Error 1


[isblank.c]

#include <ctype.h>
#include "ctypeint.h"

int (isblank)(int c)
{
     return isblank(c);
}
[/isblank.c]




Compiles perfectly with standard GCC

[Makefile]

ONLY_68K=Y
BUILD_CF=N
BUILD_FAST=N
BUILD_SOFT_FLOAT=Y
BUILD_SHORT=Y
COMPILE_ELF=N
STDIO_WITH_LONG_LONG=N


$ m68k-atari-mint-gcc --version

m68k-atari-mint-gcc (GCC) 4.6.4 (MiNT 20200504)
Copyright (C) 2011 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.

make clean

make libs

[...]

CC build/./objs/setstack.o
AR build/./libcmini.a
CC build/./objs/iio/doprnt.o
AR build/./libiiomini.a

make clean

make all

[...]

CC build/./objs/setstack.o
AR build/./libcmini.a
CC build/./objs/iio/doprnt.o
AR build/./libiiomini.a
CC build/crt0.o
CC build/minicrt0.o


Thank you for your help.

Merci.

[Freemint-discuss] Announcement - "Crash Assistant"

[Jo E. S. <jo...@on...>]

I've just released "Crash Assistant" (http://atari.joska.no/crash/), a
GEM-tool that monitors the alertpipe and catches crash notifications
from the kernel. I find this to be a useful tool when dealing with
memory violations under MiNT.

Jo Even

Re: [Freemint-discuss] Weird problem with MiNTnet

[Miro K. <mir...@gm...>]

On Mon, 3 Nov 2025 at 21:25, Stefan Niestegge <be...@ab...> wrote:

> I also wanted to start fresh HDD setup on my Falcon, with latest snapshot.
> I installed the unix stuff on my ext2 fs with the EasyMiNT installer, then
> unpacked the snapshot to the MiNT folder on C: and configured mint.cnf to
> start INIT as the shell and xaaes.cnf for SV usage and put SVethLANa driver
> into the sysdir. Configured config.if, hostname, defaultroute and
> resolve.conf for my network instead of starting dhclient at boot.
>
> Network comes up and only ping to 192.168.2.61 (my Falcon's IP) works, but
> not to router, and ping www.google.de doesn't resolve.
>
You should investigate output of "ifconfig" and "route" from your new setup
and your old setup, that should give you some clues.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Weird problem with MiNTnet

[Stefan N. <be...@ab...>]

Hello List,

I also wanted to start fresh HDD setup on my Falcon, with latest 
snapshot. I installed the unix stuff on my ext2 fs with the EasyMiNT 
installer, then unpacked the snapshot to the MiNT folder on C: and 
configured mint.cnf to start INIT as the shell and xaaes.cnf for SV 
usage and put SVethLANa driver into the sysdir. Configured config.if, 
hostname, defaultroute and resolve.conf for my network instead of 
starting dhclient at boot.

Network comes up and only ping to 192.168.2.61 (my Falcon's IP) works, 
but not to router, and ping www.google.de doesn't resolve.

BUT, if i boot into the ancient EasyMiNT 1-19-cur (using the same INIT 
from ext2 partition as with the snapshot) pinging around all works, i 
can connect to IRC and browse the web.


I managed to get the new "ready to run" 4GB FreeMiNT Distro image 
running, not sure what kernel it uses, uname -a reports 1-19a. Here i 
can also ping everything, and network works as desired.

This setup doesn't use init but calls ipconfig and route from xaaes.cnf 
instead. Therefore its not a "real" FreeMiNT setup IMHO.


I'd really like to know what the problem is. The least thing as a user 
to support you developers is actually running your latest code, and not 
say "ah well, i just run the old EasyMiNT, thats stable.".

Why would you even continue developing, then?

Greetings, and thanks for keeping FreeMiNT alive

Stefan "Beetle" Niestegge


Am 18.08.25 um 00:48 schrieb Miro Kropáček:
> Just to post an update on this... it went away the same way it 
> appeared -- without any plausible explanation. What I did was to 
> reassemble the SuperVidel, connect everything together and voila, now 
> ping 127.0.0.1 worked and so did NetUSBee's networking. I had to 
> reseat Svethlana's cable and voila, it started to work as well 
> (otherwise I was seeing a lot of error reports from svethlana's driver).
>
> How all of this is connected to pinging localhost, I do not know.
>
> On Thu, 14 Aug 2025 at 00:19, Miro Kropáček <mir...@gm...> 
> wrote:
>
>     Typo: Dec 2024. Oh and I tried also older FreeMiNT versions (1.16,
>     1.17, 1.18...)
>
>     On Thu, 14 Aug 2025 at 00:16, Miro Kropáček
>     <mir...@gm...> wrote:
>
>         Speaking of weird problems... today I have encountered
>         something equally strange and without any clue what has caused
>         it.
>
>         Basically I tried to reinstall my system from scratch. So I
>         download the bootable snapshot, add ping and set up some basic
>         static IP. Pinging my PC doesn't work. Router ditto. Local IP
>         ditto. 127.0.0.1 ditto. All I see is "PING .... 56 data bytes"
>         and that's it, no response. I can interrupt it with CTRL+C any
>         time.
>
>         So I stared at it for a while and then I tried to boot the
>         same CF card from Hatari on my PC. Didn't bother with anything
>         else than ping 127.0.0.1 and ... it worked. Swapped back to
>         the Falcon ... didn't work.
>
>         Reverted back to the snapshot, and just added 'ping' into /bin
>         (even deleted the two xif drivers in $SYSDIR). Same result:
>         Hatari OK, real machine not OK. Tried in both 030 and 060 mode.
>
>         Booting with MP enabled, nothing out of ordinary spotted.
>         Tried to copy a huge ZIP file from Hatari to CF card and unzip
>         it on Falcon (to make sure that IDE reading is OK): all fine.
>
>         Then I tried to download a snapshot from Dec 2014, which I
>         vaguely remember using: same result. Then I deleted basically
>         everything but mint.prg and inet4.xdd: same result.
>
>         As a last resort, I tried to boot the same card and default
>         snapshot on another Falcon and ... ping worked! So that leaves
>         me perplexed... I could understand all sorts of reasons why
>         the actual network interface doesn't work. But pinging
>         127.0.0.1 ??? The Falcon with non-working ping is even
>         recapped, in perfect health otherwise.
>
>         So I swapped the last thing -- the CF adapter which was
>         holding the card (from the working Falcon), and even removed
>         SuperVidel in the process (not active at that time, booting in
>         030 mode!) ... ping still stubbornly refuses to work.
>
>         As an act of desperation, I even cleaned NVRAM on the falcon,
>         as the working one has a dead NVRAM battery so it's booting
>         into ST LOW. No help.
>
>         I'm totally clueless. I guess I could try to remove the CT60e
>         but that's... that's just terrible. I guess I'll try to force
>         myself into debugging this further (i.e. to recompile 'ping'
>         from Vincent's source code) as it smells like a nice issue to
>         look at but still, I cannot think of any explanation other
>         than "bad luck".
>
>         On Sun, 18 May 2025 at 22:11, Jo Even Skarstein via
>         Freemint-discuss <fre...@li...> wrote:
>
>             Ok, haven't had much time to spend on real hardware the
>             last month, but sat down Friday night
>             and tried to figure out what the problem was. I suspected
>             either a Linux/Windows update, or a
>             router update. Most likely the latter, as the problem
>             started at the exact same time on all my
>             computers.
>
>             Turns out that it's a routing issue with my router, and
>             probably my MiNTnet configuration. When I
>             access other devices on my LAN from MiNTnet, all LAN
>             traffic goes via the router - which is set up
>             as the default route. For some unknown to me reason (I
>             know very little about network configuration)
>             this suddenly caused all my non-MiNTnet machines to not be
>             able to communicate with my MiNTnet
>             machines. Looks like packets where received by MiNTnet,
>             but the response never reached the other
>             machine. Except if that machine runs MiNTnet as well.
>
>             Adding a route specifically to my LAN solved the issue.
>             However, the dhclient script does not do this
>             so I can't use DHCP anymore. Or I probably could if I
>             modified the dhclient script, but that involves
>             another thing I don't know much and don't like - shell
>             scripts.
>
>             Jo Even
>
>
>
>             On Thu, 17 Apr 2025 19:02:57 +0000, Jo Even Skarstein via
>             Freemint-discuss <fre...@li...>
>             wrote:
>
>             >> I've ran into a weird problem with MiNTnet. Suddenly
>             none of my Ataris running MiNTnet are available to other
>             devices on my LAN, except the router. Networking between
>             my Ataris works normally, and I can ping my other devices
>             (PC's running Linux or Windows) from my Ataris but not
>             vice versa. I can't access any servers on my PC's from my
>             Ataris, but any external servers (ftp, http, mail...)
>             works fine. This happened suddenly and at the same time
>             for all my Ataris, so the problem is not caused by any
>             changes on the Atari side.
>             >>
>             >> What's strange is that if I boot TOS and run UIPtool
>             instead of MiNT/MiNTnet everything works fine. The Atari
>             is assigned the same IP as under MiNTnet (using DHCP in
>             both cases), but with UIPtool running I can access the
>             Atari from any device on my LAN.
>             >>
>             >> Any idea on what's going on?
>             >>
>             >> Jo Even
>             >>
>             >>
>             >> _______________________________________________
>             >> Freemint-discuss mailing list
>             >> Fre...@li...
>             >>
>             https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>             _______________________________________________
>             Freemint-discuss mailing list
>             Fre...@li...
>             https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>
>         -- 
>         http://mikro.atari.org
>
>
>
>     -- 
>     http://mikro.atari.org
>
>
>
> -- 
> http://mikro.atari.org
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss