Menu
▾
▴
freemint-discuss — The official FreeMiNT Mailing List
You can subscribe to this list here.
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(30) |
Dec
(10) |
| 2018 |
Jan
(44) |
Feb
(44) |
Mar
(32) |
Apr
(49) |
May
(45) |
Jun
(7) |
Jul
(15) |
Aug
(84) |
Sep
(95) |
Oct
(36) |
Nov
(88) |
Dec
(41) |
| 2019 |
Jan
(21) |
Feb
(27) |
Mar
(67) |
Apr
(25) |
May
(69) |
Jun
(45) |
Jul
(65) |
Aug
(15) |
Sep
(20) |
Oct
(42) |
Nov
(109) |
Dec
(62) |
| 2020 |
Jan
(58) |
Feb
(36) |
Mar
(84) |
Apr
(169) |
May
(325) |
Jun
(267) |
Jul
(43) |
Aug
(3) |
Sep
(27) |
Oct
(25) |
Nov
(25) |
Dec
(7) |
| 2021 |
Jan
(11) |
Feb
(66) |
Mar
(1) |
Apr
(55) |
May
(24) |
Jun
(36) |
Jul
(10) |
Aug
|
Sep
(1) |
Oct
(21) |
Nov
(2) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(98) |
Mar
(15) |
Apr
(31) |
May
(4) |
Jun
(23) |
Jul
(45) |
Aug
(15) |
Sep
(75) |
Oct
(8) |
Nov
(10) |
Dec
(12) |
| 2023 |
Jan
(5) |
Feb
(49) |
Mar
(31) |
Apr
(3) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(161) |
Sep
(8) |
Oct
(7) |
Nov
(27) |
Dec
(26) |
| 2024 |
Jan
(24) |
Feb
(35) |
Mar
(11) |
Apr
(38) |
May
(13) |
Jun
(39) |
Jul
(2) |
Aug
(24) |
Sep
(7) |
Oct
(5) |
Nov
|
Dec
(18) |
| 2025 |
Jan
(82) |
Feb
(11) |
Mar
(9) |
Apr
(13) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(38) |
Sep
(46) |
Oct
(13) |
Nov
(3) |
Dec
|
|
From: Helmut K. <hel...@is...> - 2017-11-09 21:57:51
|
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? -- |
|
From: Thorsten O. <ad...@th...> - 2017-11-09 20:38:26
|
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. |
|
From: Matthias A. <ma...@as...> - 2017-11-09 16:45:39
|
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/ |
|
From: Vincent R. <vin...@fr...> - 2017-11-09 09:36:04
|
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 |
|
From: Thorsten O. <ad...@th...> - 2017-11-09 09:34:37
|
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? |
|
From: Miro K. <mir...@gm...> - 2017-11-09 08:54:20
|
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 |
|
From: Thorsten O. <ad...@th...> - 2017-11-08 23:52:54
|
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. |
|
From: Helmut K. <hel...@is...> - 2017-11-08 23:13:51
|
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? |
|
From: Thorsten O. <ad...@th...> - 2017-11-08 03:19:25
|
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. |
|
From: Thorsten O. <ad...@th...> - 2017-11-08 00:40:22
|
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. |
|
From: Thorsten O. <ad...@th...> - 2017-11-07 22:33:02
|
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? |
|
From: Thorsten O. <ad...@th...> - 2017-11-07 22:07:24
|
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.
|
|
From: Miro K. <mir...@gm...> - 2017-11-05 23:11:20
|
> > The ".L[0-9]" are compiler generated local symbols. Aren't these already > been > supposed to be stripped by -X? > That's precisely the problem -- they should be but aren't. Formerly I used '-x' instead of it and that was stripping too much. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2017-11-05 22:59:48
|
On Sonntag, 5. November 2017 23:52:46 CET Miro Kropáček wrote:
> > Eero's proposal ("-s" for executables, "-S -X -w -N '.L[0-9]*'" for
The ".L[0-9]" are compiler generated local symbols. Aren't these already been
supposed to be stripped by -X?
|
|
From: Miro K. <mir...@gm...> - 2017-11-05 22:52:54
|
On 14 October 2013 at 11:47, Miro Kropáček <mir...@gm...> wrote:
>
> On Thu, Apr 18, 2013 at 7:43 PM, Eero Tamminen <oa...@he...> wrote:
>
>> > Globally, stripping saved many megabytes.
>>
>> I'm not interested in the ".L*" symbols as those have
>> no names, just numbers. But anything that has a name for
>> a function, I would very much like to be retained in
>> the library symbol table.
>>
>> Maybe you could use the following strip arguments:
>> -S -X -w -N '.L[0-9]*'
>> ?
>
>
> Inspired by an Atari-forum thread, I have done proper testing this time.
> Results are more than surprising. My tests were done on the complete
> gcc+binutils+mintlib+pml cross compilation installation (self made):
>
> Plain install (no stripping at all): 148 MB
> My strip ("-s" for executables, "-S -x" for libraries): 63 MB
> Eero's proposal ("-s" for executables, "-S -X -w -N '.L[0-9]*'" for
> libraries): *58 MB*
>
> Yes, with static functions like "tzload" included and still working
> (simple hello world tested). So it seems that actually Eero's "script" not
> only keeps static function names but also saves space =)
>
It took only four years and Eero's comment on AF but I have finally changed
this. So now all mintlib/gemlib/cflib/gemma builds contain static symbols,
using the command line switches above.
Vincent, if you find some time, I suggest to change the switches in your
builds as well.
--
MiKRO / Mystic Bytes
http://mikro.atari.org
|
|
From: Miro K. <mir...@gm...> - 2017-11-01 04:17:38
|
Don't worry, nothing will be lost even if atariforge.org goes down forever. On my ML page: https://mikro.naprvyraz.sk/mint/index.html I have archived also the atariforge.org one (can be found at the bottom, https://mikro.naprvyraz.sk/mint/freemint-list/index.html) -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2017-11-01 01:39:05
|
Hi, I went trough all the projects to see how much stuff is still pending (or maybe even forgotten due to unreliability of the old ML). tos.hyp: https://github.com/freemint/tos.hyp/pull/78 ... this is more a generic question as Gerhard had troubles to use the old ML + he isn't easy to reach so we still don't know whether he wants to maintain tos.hyp or not. Thorsten has tons of changes to be applied but I don't know how to proceed here. Remove the tos.hyp project and leave it to Gerhard to decide, create a fork/rename, apply Thorsten's patches and see what happens, ... ? m68k-atari-mint-gcc: https://github.com/freemint/m68k-atari-mint-gcc/pull/2 ... a small patch for native gcc 4.6.4 mintbin: https://github.com/freemint/mintbin/pull/1 ... I think safe to commit (cf)lib: https://github.com/freemint/lib/pull/1 ... I think safe to commit https://github.com/freemint/lib/pull/2 ... needs cleanup (different things mixed together, mainly the register prefix) https://github.com/freemint/lib/pull/3 ... ditto https://github.com/freemint/lib/pull/4 ... ditto mintlib: https://github.com/freemint/mintlib/pull/17 ... I think safe to commit https://github.com/freemint/mintlib/pull/20 ... register prefix (% vs motorola syntax), to be decided https://github.com/freemint/mintlib/pull/24 ... I think safe to commit https://github.com/freemint/mintlib/pull/25 ... I think safe to commit https://github.com/freemint/mintlib/pull/26 ... would be nice to split into two PRs but otherwise OK freemint: https://github.com/freemint/freemint/pull/72 ... needs cleanup, too much stuff for one PR (esp. the register prefixes) https://github.com/freemint/freemint/pull/74 ... I think safe to commit -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: François R. <re...@fr...> - 2017-10-31 18:07:21
|
Le 31/10/2017 à 13:07, François Revol a écrit : > Hi, > anyone for a MiNT talk? > > François. > (I'm not subscribed) Btw, the call for stands is still open until november 4th: https://fosdem.org/2018/news/2017-09-03-call-for-participation/ Could be nice to have a common stand with AROS for example, to show you're still around. (I'm from the Haiku project, last year we shared a table with ReactOS.) François. |
|
From: François R. <re...@fr...> - 2017-10-31 12:07:55
|
Hi, anyone for a MiNT talk? François. (I'm not subscribed) -------- Message transféré -------- Sujet : Retrocomputing devroom at FOSDEM 2018 Date : Tue, 31 Oct 2017 00:27:35 +0100 De : François Revol <re...@fr...> Pour : ar...@go... Hi, I just found out someone managed to get a retrocomputing devroom accepted at FOSDEM: https://lists.fosdem.org/pipermail/retrocomputing-devroom/2017-October/000000.html https://www.elpauer.org/2017/10/retrocomputing-devroom-call-for-participation/comment-page-1/ Who's going to propose a talk about ARAnyM??? François. |
|
From: Miro K. <mir...@gm...> - 2017-10-31 09:53:34
|
About a year after Roger's initial message we are really doing it. AtariForge was a great service back then but today it's harder and harder to use it due to its common down times <https://github.com/freemint/freemint/issues/57>. SF.net is not ideal but there aren't many free & easy to setup options available (Google Groups seems to be the only other option). We are not moving to SF.net as a project, https://sourceforge.net/p/freemint contains only basic info but the main thing is still https://freemint.github.io and its services. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Roger B. <an...@xp...> - 2016-09-22 22:30:58
|
In an attempt to improve reliability, we are now hosting the mailing list on SourceForge. Roger Burrows |
5 messages has been excluded from this view by a project administrator.
