freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] OT: getting hold of Alan H

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

As far as I know, that email address should be fine. I got an email from
him on Oct 31, he just seems to be very busy for past few months.

On 17 November 2017 at 11:18, Roger Burrows <an...@xp...> wrote:

> I sent a message to Alan Hourihane a month or so ago (via fairlite.co.uk),
> but
> got no response.  Does anyone have an alternative email address?
>
> Roger
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] OT: getting hold of Alan H

[Roger B. <an...@xp...>]

I sent a message to Alan Hourihane a month or so ago (via fairlite.co.uk), but 
got no response.  Does anyone have an alternative email address?

Roger

[Freemint-discuss] [SPAM]

    <p....@sc...>
Cc: <fre...@li...>
From: Peter Slegg <p....@sc...>
Subject: Re: [Freemint-discuss] Memory protection
Reply-To: Peter Slegg <p....@sc...>
X-Mailer: MyMAIL Rev:1.96.04.14145 (Atari/(STiK/STinG/GlueSTiK))
X-Hardware: Atari Milan
MIME-Version: 1.0
Date: Thu, 16 Nov 2017 22:46:54 +0000 (GMT)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <002...@sm...>
References: <CAN5rfbTGHgwmnpFAqM9DQAEVEjRepZ=JB5...@ma...>
In-Reply-To: CAN5rfbTGHgwmnpFAqM9DQAEVEjRepZ=JB5...@ma...

I was puzzled at first but I think I understand.

With MP it "crashes" and cannot restore the vectors.

Without MP doesn't crash and manages to restore the vectors so Mint carries
on as normal.


Peter



On Wed, 15 Nov 2017 10:52:06 , Miro Krop=E1?ek wrote:
> Unfortunately, this is a side effect of bad Atari design and FreeMiNT can
> do very little about it. I'm 99% sure is that what you have obsessed is
> that Netsurf has hijacked the IKBD vectors, crashed due to a (valid) memory
> violation and of course, couldn't restore the vectors back to its original
> state.
>
> On 15 November 2017 at 09:00, Peter Slegg <p....@sc...> wrote:
>
> >
> > At the weekend I gave MP another go.
> >
> > At first it was ok. I was using Netsurf but when I exited there
> > was a memory violation error.
> >
> > It was trapped but then the mouse pointer went very sticky.
> > It moved, stuck, moved stuck.
> >
> > I have seen this when something has crashed badly but wasn't expecting it
> > with MP.
> >
> > Restarting Xaaes didn't help and I had to reboot.
> >
> >
> > Later it did it again with another app so I reverted to non-MP.
> >
> >
> >
> >
> > Peter
> >
> >
> >
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Freemint-discuss mailing list
> > Fre...@li...
> > https://lists.sourceforge.net/lists/listinfo/freemint-discuss
> >
>
>
>

Re: [Freemint-discuss] Memory protection

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

Unfortunately, this is a side effect of bad Atari design and FreeMiNT can
do very little about it. I'm 99% sure is that what you have obsessed is
that Netsurf has hijacked the IKBD vectors, crashed due to a (valid) memory
violation and of course, couldn't restore the vectors back to its original
state.

On 15 November 2017 at 09:00, Peter Slegg <p....@sc...> wrote:

>
> At the weekend I gave MP another go.
>
> At first it was ok. I was using Netsurf but when I exited there
> was a memory violation error.
>
> It was trapped but then the mouse pointer went very sticky.
> It moved, stuck, moved stuck.
>
> I have seen this when something has crashed badly but wasn't expecting it
> with MP.
>
> Restarting Xaaes didn't help and I had to reboot.
>
>
> Later it did it again with another app so I reverted to non-MP.
>
>
>
>
> Peter
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Memory protection

[Peter S. <p....@sc...>]

At the weekend I gave MP another go.

At first it was ok. I was using Netsurf but when I exited there
was a memory violation error.

It was trapped but then the mouse pointer went very sticky.
It moved, stuck, moved stuck.

I have seen this when something has crashed badly but wasn't expecting it
with MP.

Restarting Xaaes didn't help and I had to reboot.


Later it did it again with another app so I reverted to non-MP.




Peter

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Samstag, 11. November 2017 14:11:21 CET Peter Slegg wrote:
> I've just joined this new list and was going to post about a timestamp
> issue that I had reaised a few years ago. I see there is a discussion
> about it all ready.

You can view the archive at https://sourceforge.net/p/freemint/mailman/
freemint-discuss/ if you didn't get the whole thread.

> On /f there is a file with a timestamp of 19:26 and on /l it is
> 20:26.  It looks like GMT and BST timeszones.

If the drives were attached to different hardware, and you had different 
timezone settings there, that's possible.

> I rsync /f to /l and when rsync checks them it looks like it is
> updating the file. However, afterwards the updated file on /l is still
> showing 20:26
> 
> Shouldn't they be identical after rsync ?

Hm, don't know. Wouldn't rsync skip the file, if it determines that the 
contents are the same? At least, the problem we discussed should not occur 
when copying from FAT to FAT on the same machine. Things might be different if 
you actually do that over network.

> The second issue is that during summer time (BST) the clock (shown in
> Multistrip) only shows GMT (BST -1) so I think that the timezone isn't
> working.

You have to run tzinit during boot time to set up the timezone. And you have 
to tell it wether your hardware clock is running in local time, or utc. After 
that, you should run date in a shell to check it, if that does not produce the 
correct result, you should check wether it is using the correct timezone 
database. tzinit is part of the mintlib. I'm not sure wether the compiled 
database is downloadable somewhere, the problem is that you can't create it 
when cross-compiling, the tools are not prepared for that. There should be 
some instructions in the tz directory of the mintlib source.

Thorsten

Re: [Freemint-discuss] Mint handling of file timestamps

[Peter S. <p....@sc...>]

I've just joined this new list and was going to post about a timestamp
issue that I had reaised a few years ago. I see there is a discussion
about it all ready.

My situation is this. I am syncing two drives with rsync.

I have 2 FAT partitions, /f and /l, they are all ready very similar
because they were copied several months ago.

On /f there is a file with a timestamp of 19:26 and on /l it is
20:26.  It looks like GMT and BST timeszones.

I rsync /f to /l and when rsync checks them it looks like it is
updating the file. However, afterwards the updated file on /l is still
showing 20:26

Shouldn't they be identical after rsync ?


The second issue is that during summer time (BST) the clock (shown in
Multistrip) only shows GMT (BST -1) so I think that the timezone isn't
working.


Peter

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Samstag, 11. November 2017 11:02:54 CET Thorsten Otto wrote:
> I think i have to find out what really gets written to the disk there

Ok, did that now. Created a plain FAT image (with mkdosfs), and mounted that 
with -t msdos to /mnt. Result:

$ touch -d "2017-07-15 13:00:00" /mnt/bla
$ ls -l --full-time /mnt/bla
-rwxr-xr-x 1 root root 0 2017-07-15 13:00:00.000000000 +0200 /mnt/bla

$ touch -d "2017-11-05 13:00:00" /mnt/bla 
$ ls -l --full-time /mnt/bla
-rwxr-xr-x 1 root root 0 2017-11-05 13:00:00.000000000 +0100 /mnt/bla

(+0200 was the daylight saving time in effect in July here, +0100 is the
 current timezone offset).

On disk, i get:

00005800: 42 4C 41 20  20 20 20 20  20 20 20 20  00 00 00 00   "BLA 
        ...." 
00005810: 00 00 00 00  00 00 00 60  EF 4A 00 00  00 00 00 00 
  ".......`.J......"

for the first, which is 2017-07-15 12:00:00 when i convert the stamp without 
applying any offset, and

00005800: 42 4C 41 20  20 20 20 20  20 20 20 20  00 00 00 00   "BLA 
        ...." 
00005810: 00 00 00 00  00 00 00 68  65 4B 00 00  00 00 00 00 
  ".......heK......"


for the 2nd, which is 2017-11-05 13:00:00. So it seems linux has the same 
problems, the stamp for the first file (on disk) is off by 1 hour. What 
happens is that:

- touch converts the time i specified to an UTC time, subtracting the offset 
of +0200 that was in effect at that time.
- the kernel adds the current time offset before writing the stamp, because 
for FAT a local time should be stored.

Not very pleasing. That means, if i wait half a year, and daylight savings 
time is in effect again, ls -l will suddenly report a different time.

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Samstag, 11. November 2017 10:21:12 CET Helmut Karlowski wrote:

>So if you send the image to someone in China he will see your local times,  
>but for a TOS-FS there might be no other way.

Yes, that's just the design flaw of FAT filesystem to store local times.
The linux kernel has a workaround for this, by allowing to specify a specific 
timezone offset for FAT to use, rather than the current one. Strangly, beside 
this extra option, it otherwise seems to behave the same, just adding/
subtracting that offset. I still have to figure out why it obviously works 
there, maybe glibc does some magic i havn't found yet. Or the kernel is just 
lying. I think i have to find out what really gets written to the disk there.

> That would mean that MiNT always tries to returns local time?

That depends on the function call, and thats the problem. The ability to 
return UTC timestamps was added later (maybe in version 1.15.4, when Fstat64() 
was implemented). By returning UTC times, the burden to convert that to a 
local time is left to the application, which (by using mintlib) has no problem 
with that. Unfortunately, there where already existing interfaces that are 
expected to return a local time. That includes Fxattr (with was previously 
used to implement the stat() function in mintlib), and Dxreaddir, which 
returns the same structure. Dxreaddir has no direct counterpart in mintlib, 
but some applications (most likely desktops), still use it to avoid a separate 
stat() call for every file to display (although that shouldn't make much 
difference, since the kernel internally does the same, you only save the extra 
roundtrip to gemdos).

>So it should be like this:
>TOS-FS: file-times are local-time
>Others: file-times are utc.

Yes, but even for filesystems that already implement it (i think all but TOS-
FS), there are calls that convert to/from local time (like fcntl(FUTIME)). 
Also a plain Fdatime() call is interpreted as specifying a local time.

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 11.11.2017, 09:21 Uhr, schrieb Helmut Karlowski:

> I see on getstat64,xfs_xdd.c:
>
>      /* no native UTC extension
>       * -> convert to unix UTC
>       */
>      stat->atime.high_time = 0;
>      stat->atime.time = unixtime (xattr.atime, xattr.adate) + timezone;
>      stat->atime.nanoseconds = 0;
>
> That would mean that MiNT always tries to returns local time? And  
> timezone is a constant not taking account of the time-offset of the  
> actual time?

Actually the other way: It tries to convert the local time from the file  
to utc, but it's still not right. At least for Non-TOS-FS it should not  
change anything.

--

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 10.11.2017, 03:58 Uhr, schrieb Thorsten Otto:

>> Shall the file-time be stored in utc or local time on disk?
>
> Since it is a plain tos/msdos filesystem (no vfat), it can only be  
> stored in
> local time.

So if you send the image to someone in China he will see your local times,  
but for a TOS-FS there might be no other way.

>
> I think the only possible solution is to add some flag to Dopendir, to  
> tell
> Dxreaddir that it should return the timestamps as UTC so the application  
> can
> do the calculation. Of course, that would also require changes to the
> applications using it directly (like teradesk), and mintlib for all  
> others.
> For other cases, like stat() and Fdatime(), there are already  
> alternatives
> that should work, like Fstat64() and fcntl(FUTIME_UTC).

Yes, store the times in UTC. Maybe mintlib can set a flag to tell the  
kernel about it's preference, and old apps would still work as before.

As far as I see, tools like ls expect utc and call localtime to get the  
tm-content in local-time representation.

So it should be like this:

TOS-FS: file-times are local-time
Others: file-times are utc.

I see on getstat64,xfs_xdd.c:

     /* no native UTC extension
      * -> convert to unix UTC
      */
     stat->atime.high_time = 0;
     stat->atime.time = unixtime (xattr.atime, xattr.adate) + timezone;
     stat->atime.nanoseconds = 0;

That would mean that MiNT always tries to returns local time? And timezone  
is a constant not taking account of the time-offset of the actual time?

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Matthias A. <ma...@as...>]

Am Thu, 9 Nov 2017 17:27:41 +0100
schrieb Matthias Arndt <ma...@as...>:

> Am Thu, 09 Nov 2017 10:34:28 +0100
> schrieb Thorsten Otto <ad...@th...>:
> 
> 
> > 
> > PS2.: is that simonsunnyboy from the forum?  
> 
> No, it's not me. I am using mfro's work on using the existing gcc
> without the Mintlib, esp. his startup code as base and linker flags.

For completeness of the record, my starting point some years back back
then was this:

http://forum.atari-home.de/index.php?topic=10475.0

A lot of my subsequent work is on GitHub:

https://github.com/simonsunnyboy/stlibs4gcc

This includes a lot of former GFABASIC accessible INLINEs and AHCC
stuff ported for GCC use.

It is mainly of interest for game and demo coding, not for clean
applications.

Regards,
Matthias

-- 
http://final-memory.org/

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Donnerstag, 9. November 2017 22:57:41 CET Helmut Karlowski via Freemint-
discuss wrote:
> That is the same symptom that can be observed when accessing files on
> host-fs.

Not really. The image is a tos filesystem, so the hostfs is not involved at 
all. You will see that from the flags, FS_EXT_3 is not set there (unfortunately 
the xfs name is not easily accessible there).

>Shall the file-time be stored in utc or local time on disk?

Since it is a plain tos/msdos filesystem (no vfat), it can only be stored in 
local time.

I think the only possible solution is to add some flag to Dopendir, to tell 
Dxreaddir that it should return the timestamps as UTC so the application can 
do the calculation. Of course, that would also require changes to the 
applications using it directly (like teradesk), and mintlib for all others. 
For other cases, like stat() and Fdatime(), there are already alternatives 
that should work, like Fstat64() and fcntl(FUTIME_UTC). 

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 09.11.2017, 21:38 Uhr, schrieb Thorsten Otto:

> On Mittwoch, 8. November 2017 23:52:09 CET Helmut Karlowski via Freemint-
> discuss wrote:
>> Do you have a testcase that demonstrates the problem without any
>> aranym-interaction?
>
> Although also running under Aranym, i just did a test with a freshly  
> created
> tos filesystem image, so the hostfs is not involved here. By inserting  
> debug
> printfs, i get following output from what is returned by Dxreaddir:
>
> pid  13 (desktop): getxattr 67E: 2017/06/04 13:23:30
> pid  13 (desktop): getxattr 67E: 2017/11/08 05:12:30
>
> The 67E are the filesystem flags. The same two files, mounted on linux:
>
> $ ls -l /mnt
>
> -rwxr-xr-x 1 root root 37146  4. Jun 14:23 emucicn.rsc
> -rwxr-xr-x 1 root root  1209  8. Nov 05:12 newdesk.inf

That is the same symptom that can be observed when accessing files on  
host-fs.

> So something is definitely wrong there.

Shall the file-time be stored in utc or local time on disk?

--

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Mittwoch, 8. November 2017 23:52:09 CET Helmut Karlowski via Freemint-
discuss wrote:
> Do you have a testcase that demonstrates the problem without any
> aranym-interaction?

Although also running under Aranym, i just did a test with a freshly created 
tos filesystem image, so the hostfs is not involved here. By inserting debug 
printfs, i get following output from what is returned by Dxreaddir:

pid  13 (desktop): getxattr 67E: 2017/06/04 13:23:30 
pid  13 (desktop): getxattr 67E: 2017/11/08 05:12:30

The 67E are the filesystem flags. The same two files, mounted on linux:

$ ls -l /mnt

-rwxr-xr-x 1 root root 37146  4. Jun 14:23 emucicn.rsc 
-rwxr-xr-x 1 root root  1209  8. Nov 05:12 newdesk.inf

So something is definitely wrong there.

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Matthias A. <ma...@as...>]

Am Thu, 09 Nov 2017 10:34:28 +0100
schrieb Thorsten Otto <ad...@th...>:


> 
> PS2.: is that simonsunnyboy from the forum?

No, it's not me. I am using mfro's work on using the existing gcc
without the Mintlib, esp. his startup code as base and linker flags.

Regards,
Matthias

-- 
http://final-memory.org/

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Vincent R. <vin...@fr...>]

On 09/11/2017 at 09:54, Miro Kropáček wrote:
> thanks to user Simon Krix, known as Smonson on AF/Exxos forum I have
> discovered his project and using plain ELF m68k gcc for producing Atari
> binaries: https://github.com/smonson78/ataricc/blob/master/Makefile

Good to see such alternatives.
This really helps to better understand potential GCC solutions.

-- 
Vincent Rivière

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Thorsten O. <ad...@th...>]

On Donnerstag, 9. November 2017 09:54:11 CET Miro Kropáček wrote:
> Basically he takes plain m68k gcc, compiles everything and links using a
> special ld script and then just converts into an atari binary using vlink.

Thats a bit simpler than the browngcc attempt, but still needs an additional 
step in linking. And you still need libraries compiled for this target.

Also, if you look at the flags (-ffreestanding, -fno-rtti etc.) that means gcc 
does not do any optimizations to builtin function, you can't compile most c++ 
programs and similar quirks. I think he will get the same problems as me with 
global constructors for example: the elf compiler will not generate a call to 
___main(), so they don't get executed. And if i understand it right, he is 
using the libc from vbcc, which is good enough for most tos programs, but 
certainly not for gnu packages (or is he using his own version? not sure)

The main purpose why i attempted on building my port was to be able to just do 
a "./configure target=m68k-atari-mintelf; make; make install". And if you look 
at the scripts, this is actually almost everything that is done there. The 
only hassle is to build the different libraries for different cpus.

>One can produce lto'ed binaries, too.

Yes, thats the point, building them. Having to write the scripts is one thing, 
but having to patch all configure scripts of the packages to get them compiled 
with an unknown target, and adding special flags, and additional steps to 
produce binaries (lots of libraries like iconv, bzip etc also build 
executables), is another.

PS.: oh i just saw, he is using his own version of crt startup, executing the 
constructors manually.

PS2.: is that simonsunnyboy from the forum?

[Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

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

Hi,

thanks to user Simon Krix, known as Smonson on AF/Exxos forum I have
discovered his project and using plain ELF m68k gcc for producing Atari
binaries: https://github.com/smonson78/ataricc/blob/master/Makefile

Basically he takes plain m68k gcc, compiles everything and links using a
special ld script and then just converts into an atari binary using vlink.

So it's something like The Brown Guys used, just simpler and more
straightforward. One can produce lto'ed binaries, too.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Mittwoch, 8. November 2017 23:52:09 CET Helmut Karlowski via Freemint-
discuss wrote:

>Do you have a testcase that demonstrates the problem without any  
>aranym-interaction?

No, unfortunately not, i don't have any real hardware anymore. 

Its a bit difficult to follow what happens, but i think the problem should be 
clear. When using functions like Fdatime() to modify the filetime, and that 
time has to be converted to UTC, mint uses only the global timezone variable, 
which is only valid for the current local time. It does not try to compute the 
timezone offset that was in effect at the time that should be set. Hence the 
UTC time written to disk is *not* correct.

I think that should be visible when copying files from fat to ext2fs, having 
times that are from a different timezone offset than the current, like in my 
example. Then use "ls -l" in the console to view their modification times. 
Don't use teradesk or some desktop for this; if it is using Dxreaddir() it 
will report the correct time, but only because the same offset is just applied 
again. ls from the coreutils however should be able to calculate the timezone 
offset of the time, using the tz package from mintlib. Compare that time to 
the modification time of the original file.

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 08.11.2017, 04:19 Uhr, schrieb Thorsten Otto:

> - If you think thats a bug in Teradesk, or Aranym: thats not quite true
> either. That inconsistency will also occur when using only ext2fs  
> filesystems.

On an ext2-fs inside MiNT (no host-fs, only ext2) the times of files  
created in summertime are correct. At least if the program is using  
mintlib (TZ=Europe/Berlin).

I only observe discrepancies between host-fs-file-time and MiNT-file-time  
- for example st_mtime differs, using the ancient version of mintlib I use  
with pure-c. I once tried to fix it in hostfs.cpp in my private  
aranym-version (something with tm_gmtoff) but that is still not 100% it  
seems.

> The problem here is that functions like Fstat64() report UTC timestamps  
> (if
> the filesystem supports it, but most do, except tosfs), while eg.  
> Dxreaddir()
> returns the extended information in the old xattr structure, where the
> timestamps are converted to local time, using the global timezone  
> variable.

Do you have a testcase that demonstrates the problem without any  
aranym-interaction?

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

Some 2 more notes on this:

- if you think you can fix this by calling tzinit with --localtime, or --utc, 
you are wrong: that only affects functions like Tgetdate() and 
Tgettimeofday(). Same for the gmtime config setting in Aranym.

- If you think thats a bug in Teradesk, or Aranym: thats not quite true 
either. That inconsistency will also occur when using only ext2fs filesystems. 
The problem here is that functions like Fstat64() report UTC timestamps (if 
the filesystem supports it, but most do, except tosfs), while eg. Dxreaddir() 
returns the extended information in the old xattr structure, where the 
timestamps are converted to local time, using the global timezone variable.

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

To illustrate the issue:



The upper half shows 2 files in teradesk, the lower the same 2 files on the 
host. etos512k.img was created a few days ago, when we had summer time here in 
germany, and mint was running with a timezone offset of -7200. The other file i 
just touched, with summertime being over, and mint now running with a timezone 
offset of -3600. The 2nd file has the correct time, but etos512k.img is off by 
one hour.

[Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

Hi,

when tracking down what occurs to me as a bug in aranym's implementation of 
the hostfs, it turned out be a general problem in mint.

When setting/retrieving timestamps (either through Fstat64(), or Fdatime(), or 
some Fcntl(FUTIME)), at certain places the kernel timezone variable is added/
subtracted. That is totally nonsense of course, that timezone offset is only 
valid for the current local time, but not for some arbitrary time in the past. 
if works when used on just created files, but not eg. when copying files from a 
TOS partition (which is expected to use local doslike timestamps) to an 
extf2fs filesystem, or in my case to the hostfs which behaves the same in this 
manner (it has the FS_EXT_3 flag set, and uses UTC timestamps).

To fix this, Mint must be able to compute the timezone offset for some given 
local time, which basically means implementing most of the tz package as 
already used by eg. mintlib. Main problem with this is that it relies on some 
database which is stored on a filesystem... Not only that this leads to an 
chicken/egg problem, but it would also make calculating the correct offset 
awfully slow. Any ideas how to solve this?

Re: [Freemint-discuss] [MiNT] binutils-2.23.2 and gcc-4.6.4

[Thorsten O. <ad...@th...>]

On Montag, 6. November 2017 00:11:12 CET Miro Kropáček wrote:
> That's precisely the problem -- they should be but aren't.
 
Seems to be an assembler problem. When i compile a simple test program here 
with the native gcc, i get:
~ $ nm bla.o         
                U do_nothing 
0000000000000034 T main 
0000000000000000 T test 
0000000000000000 b x

When i compile the same program with the cross-compiler, i get:
$ m68k-atari-mint-nm bla.o         
00000014 t .L2 
0000000a t .L3 
0000000a t .LBB2 
00000010 t .LBE2 
00000000 t .LFBB1 
00000024 t .LFBB2 
00000024 t .Lscope1 
00000032 t .Lscope2 
00000000 t .Ltext0 
        U ___main 
        U _do_nothing 
00000024 T _main 
00000000 T _test 
00000034 b _x

So the native assembler seems to already omit those symbols from the object 
file. And m68k-atari-mint-strip does indeed not remove them (also not the one 
from binutils-2.29). So both seems to need fixing.
 
>Formerly I used '-x' instead of it and that was stripping too much.
 
Yes, that  will strip all local symbols, even the ones from static functions. 
Although i think the Hatari debugger can not cope very well with those, at 
least i get lots of warnings when the same static name is used in more than 
one place.