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
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Vincent R. <vin...@fr...> - 2024-02-16 10:53:51
|
On 15/02/2024 at 10:51, Miro Kropáček wrote: > 6) gdbserver is still unavailable. I will work on it in a few weeks. > Stay tuned. > > Eagerly awaiting this. With reliable TCP/IP connection (SuperVidel's and > CTPCI's 2 MB/s) debugging of hardware-specific quirks will be yet > another level of joy. If you coded your apps like a decent citizen (i.e. > no Super() as the first thing in main() ;-)). Another option is to run sshd on your Falcon, then connect using ssh/PuTTY from a PC. And run gdb from there. For text-based programs, that will work. For others... you will see. -- Vincent Rivière |
|
From: Vincent R. <vin...@fr...> - 2024-02-15 19:22:32
|
On 15/02/2024 at 18:56, Markus Fröschle wrote: > What I meant was a MiNT extension that would allow to access data > outside the current processes address range. That's probably only a > change in the Ptrace system call (that would only be active with a > certain setting in MINT.CNF) allowing reads and writes outside the > current process' address space. Ptrace implementation is rather straightforward. So that would probably be possible. https://github.com/freemint/freemint/blob/master/sys/ptrace.c -- Vincent Rivière |
|
From: Markus F. <ma...@mu...> - 2024-02-15 17:56:21
|
Am Donnerstag, dem 15.02.2024 um 17:15 +0100 schrieb Vincent Rivière: > On 15/02/2024 at 16:49, Thorsten Otto wrote: > > But maybe similar extensions already exist for embedded targets? > > If I'm not wrong, at the era where ColdFire wasn't obsolete yet, > there > was some GDB version able to remote-debug programs running on the > evaluation boards through the BDM interface (remote hardware > debugger). > I never tried that. But we could have a look to such thing to see how > it > works. That would be a starting point. > I had that running, sources (that worked with an older version of m68k- elf-gdb) are here: https://sourceforge.net/p/bdm/code/ci/master/tree/ It basically brought a new target: m68k-elf-bdm. But that's not what I meant (while it would of course be very handy if that would work as well). What I meant was a MiNT extension that would allow to access data outside the current processes address range. That's probably only a change in the Ptrace system call (that would only be active with a certain setting in MINT.CNF) allowing reads and writes outside the current process' address space. On a traditional Unix system, you would basically just mmap() /dev/mem and read/write from/to there. |
|
From: Vincent R. <vin...@fr...> - 2024-02-15 16:15:31
|
On 15/02/2024 at 16:49, Thorsten Otto wrote: > But maybe similar extensions already exist for embedded targets? If I'm not wrong, at the era where ColdFire wasn't obsolete yet, there was some GDB version able to remote-debug programs running on the evaluation boards through the BDM interface (remote hardware debugger). I never tried that. But we could have a look to such thing to see how it works. That would be a starting point. -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2024-02-15 15:49:28
|
On Donnerstag, 15. Februar 2024 16:39:11 CET Markus Fröschle wrote: > Opinions? That would surely be useful. However, there is no interface for that, neither in gdb nor in mint. Currently, gdb uses the more-or-less standard ptrace() system call to examine memory, and that is restricted to the memory of the process being traced. But maybe similar extensions already exist for embedded targets? |
|
From: Markus F. <ma...@mu...> - 2024-02-15 15:39:28
|
Am Donnerstag, dem 15.02.2024 um 10:51 +0100 schrieb Miro Kropáček: > > I've just used it recently. Pure joy. It's so easy to forget how > debugging eases a programmer's life. ;) After all those years! > > > ... > > 6) gdbserver is still unavailable. I will work on it in a few > > weeks. Stay tuned. > > > > Eagerly awaiting this. With reliable TCP/IP connection (SuperVidel's > and CTPCI's 2 MB/s) debugging of hardware-specific quirks will be yet > another level of joy. If you coded your apps like a decent citizen > (i.e. no Super() as the first thing in main() ;-)). Same. But about "hardware-specific quirks": currently, gdb can only see the address space of the local process. I know that's a MiNT limitation and on purpose (for good reason) but it would be handy if there would be a MiNT "no guardrails"-mode that would allow to read and write outside this address space (e.g. to access hardware registers, system variables or to debug drivers). Opinions? |
|
From: Vincent R. <vin...@fr...> - 2024-02-15 10:59:10
|
On 15/02/2024 at 11:34, Thorsten Otto wrote: > See also > https://www.atari-forum.com/viewtopic.php?p=450311#p450311 Ah, this is interesting. I missed that thread. You gave a solution: > $ infocmp tw100 | sed 's/ll=\\E\[24H, //' | tic - > ... > Eventually, depending on access rights, the result will be written > to $HOME/.terminfo/t/tw100 instead of the system-wide > /usr/share/terminfo/t/tw100 This explains how that strange /root/.terminfo directory appears. -- Vincent Rivière |
|
From: Vincent R. <vin...@fr...> - 2024-02-15 10:48:44
|
On 15/02/2024 à 10:51, Miro Kropáček a écrit : > Hmm, perhaps we should include it in the snapshots. Is there a specific > test case where I can see the corruption to verify that it works OK now? Definitely, this new tw100 definition must be updated everywhere. The patch for terminfo in ncurses sources is easy (found by Thorsten): just get rid of "ll" definition. http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/ncurses-6.4-mintelf-20230910.patch.xz Then the resulting binary "tw100" must be used in FreeMiNT binary distributions. The simplest way to see if a setup is OK is by running the "infocmp" tool. If the "ll" variable is present, that's wrong (because of the hardcoded "24 lines" in the value). If ll isn't present (kund is followed by nel), then that's OK. As said previously: don't be fooled by the /root/.terminfo folder! If it is present, it will override the system-wide terminfo database, so the new tw100 won't be used. I had that surprise in my old EasyMiNT setup. The fix didn't work. Again, the "infocmp" tool helps for diagnostic: it displays the path of the current terminal definition file on the first line. If it displays /root/.terminfo/..., then remove it. But the best way to check everything is OK is of course inside GDB itself. Unfortunately, I don't know an easy way to check that. For sure, I reproduced the problem this way: - Open TosWin2, and enlarge the window a bit - Run GDB in TUI mode - Debug some program, and step inside functions - Every time a function is entered/left, the screen gets corrupted. Mainly, the (gdb) prompt appears in the middle. This can easily be fixed with ^L, but will occur soon again. - On the other hand, with the tw100 fix, I didn't notice any screen corruption in the TUI. Not to be confused with another issue: When the debugged program does screen output (with printf for example), the TUI screen is messed. Use ^L to fix. This is the expected behaviour, not a bug. Note that I also regularly use GDB on the full-screen BIOS console using the st52 terminfo definition. It works like a charm (no update needed). Only caveat: new GDB uses ANSI colors by default (without terminfo), and those ANSI colors are incompatible with st52. The solution is to set the NO_COLOR environment variable to something in order to disable colors. For example: NO_COLOR=1 gdb myprog.tos https://no-color.org/ -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2024-02-15 10:35:02
|
On Donnerstag, 15. Februar 2024 10:51:21 CET Miro Kropáček wrote: > Is there a specific test case where I can see the corruption to verify that > it works OK now? Without the patch, gdb will place the cursor somewhere in the middle of the screen whenever you enter it (at least when the window is larger than 24 lines). The buggy terminfo description has a hardcoded value of ``ll=\E\[24H`` (ll is the entry for "move cursor to lower left of screen"). See also https:// www.atari-forum.com/viewtopic.php?p=450311#p450311 |
|
From: Miro K. <mir...@gm...> - 2024-02-15 09:51:44
|
On Thu, 15 Feb 2024 at 00:18, Vincent Rivière <vin...@fr...> wrote: > 4) As said in other messages, native FreeMiNT GDB 14.1 is available and > works well. Find binaries and quickstart here: > http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb/ > > 5) GDB TUI mode is very nice for full-screen debugging. To use it with I've just used it recently. Pure joy. It's so easy to forget how debugging eases a programmer's life. ;) After all those years! TosWin2 without screen corruption, be sure to have an updated tw100 > terminfo > definition. Thorsten found that the "ll" setting was wrong, and provided a > fix. To upgrade your system, you can extract the file > usr/share/terminfo/t/tw100 from that archive: > > http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/ncurses/ncurses-6.4-bin-mintelf-20240121.tar.xz > Then replace it on your system. > Hmm, perhaps we should include it in the snapshots. Is there a specific test case where I can see the corruption to verify that it works OK now? 6) gdbserver is still unavailable. I will work on it in a few weeks. Stay > tuned. > Eagerly awaiting this. With reliable TCP/IP connection (SuperVidel's and CTPCI's 2 MB/s) debugging of hardware-specific quirks will be yet another level of joy. If you coded your apps like a decent citizen (i.e. no Super() as the first thing in main() ;-)). -- http://mikro.atari.org |
|
From: Vincent R. <vin...@fr...> - 2024-02-14 23:17:44
|
Hi, here is a quick update. 1) I've rebuilt all the Cygwin binaries. Everything is available on the main page: http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/ 2) Ubuntu binaries are now my main target. I may update them more frequently: http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/ubuntu.php 3) binutils 2.42 have been released recently. I've upgraded the mintelf cross-tools accordingly. That still works well, no more no less. 4) As said in other messages, native FreeMiNT GDB 14.1 is available and works well. Find binaries and quickstart here: http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb/ 5) GDB TUI mode is very nice for full-screen debugging. To use it with TosWin2 without screen corruption, be sure to have an updated tw100 terminfo definition. Thorsten found that the "ll" setting was wrong, and provided a fix. To upgrade your system, you can extract the file usr/share/terminfo/t/tw100 from that archive: http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/ncurses/ncurses-6.4-bin-mintelf-20240121.tar.xz Then replace it on your system. Note: If the /root/.terminfo folder exists on your setup, remove it. Otherwise the system-wide tw100 definition won't be used. You can check that the right one is used by running the "infocmp" tool. See the tw100 path on the first line. 6) gdbserver is still unavailable. I will work on it in a few weeks. Stay tuned. 7) As said previously, I compiled a bunch of updated software for FreeMiNT with that cross-compiler: http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/ Everything works perfectly. So we can reasonably say that the new mintelf toolchain is reliable. Enjoy 😃 -- Vincent Rivière |
|
From: Vincent R. <vin...@fr...> - 2024-02-12 14:49:41
|
On 12/02/2024 at 11:45, Miro Kropáček wrote: > ... do we have to reimplement our binutils patch from scratch? Er... Most of the mintelf patch is inside the BFD library. I haven't looked at the mold sources. But if mold doesn't use the BFD library, yes, the mintelf patch will have to be reimplemented. There is already a similar example: the readelf and elfedit tools, shipped with binutils, don't use the BFD library. Other examples are the mintbin tools. In all those cases, I indeed had to reimplement the mintelf patch. But in the case of those small tools, the changes are really trivial. This is possible as PRG/ELF is almost ELF: only the ELF header isn't at standard place, everything else is standard ELF. So patching read-only tools (or almost read-only) is a piece of cake. But the big part is indeed in the linker, to move the ELF header a bit farther. This is theoretically very simple. I produced the first PRG/ELF executables using a custom tool from mine, this was really straightforward. But all the ld/BFD code is designed to write the ELF header at the start of the file. Moving the ELF header farther with that code isn't trivial, because it requires patching the existing code at several places where it assumes that file offset = offset from start of the ELF header. So patching mold might be non-trivial, because just like ld/BFD, it is the component which produces the executables and computes the offsets. -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2024-02-12 13:27:30
|
On Montag, 12. Februar 2024 12:28:31 CET Miro Kropáček wrote: > I think the idea isn't to get rid of binutils, just replace the ld That was already attempted by introducing gold, but it looks like it is not as well maintained as ld, and as far as i can tell, no distribution really uses it. So i think it is unlikely that this switch will ever happen. And even if they do, it is unlikely that ld will be removed from binutils. So for now, there is not much to fear about. And even if that happens, we now have a really recent binutils, and can stick to it for a while (remember that our snapshot builds still use binutils 2.30 for the a.out toolchains). |
|
From: Miro K. <mir...@gm...> - 2024-02-12 11:28:55
|
On Mon, 12 Feb 2024 at 12:01, Thorsten Otto <ad...@th...> wrote: > Also, binutils is not just ld, and from what i've seen, mold is really > only the linker, not anything else like ar, ranlib etc. Imho it would not > make much sense to use it, when you need binutils anyway, even if it is > faster. > I think the idea isn't to get rid of binutils, just replace the ld (maybe even by the binutils team themselves). And I can't say I don't see some sense in that move, linking m68k scummvm, even as restricted as ours (i.e. ~20 MB binary in the end) takes usually about 10 seconds on my PC (mostly due to not using SSD for my /home but anyway). -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-02-12 11:00:32
|
On Montag, 12. Februar 2024 11:45:15 CET Miro Kropáček wrote: > I've been wondering, when this becomes reality I hope that this will never happen. I wonder how he can state that mold "is the only linker supporting all gcc features". Also, binutils is not just ld, and from what i've seen, mold is really only the linker, not anything else like ar, ranlib etc. Imho it would not make much sense to use it, when you need binutils anyway, even if it is faster. >do we have to reimplement our binutils patch from scratch? Haven't looked at the code of mold, but most likely, yes. It does not have anything in common with binutils. |
|
From: Miro K. <mir...@gm...> - 2024-02-12 10:45:35
|
Hi, I've been wondering, when this becomes reality: https://fosdem.org/2024/schedule/event/fosdem-2024-2606-can-the-mold-linker-be-usr-bin-ld-/ ... do we have to reimplement our binutils patch from scratch? -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-02-11 12:35:54
|
On Sonntag, 11. Februar 2024 12:56:21 CET Markus Fröschle wrote: > My libpng16.a is about 350K That's quite large. Mine (for 68k) is much smaller: $ ls -l libpng16.a libz.a -rw-r--r-- 1 sebilla users 223438 11. Okt 12:01 libpng16.a -rw-r--r-- 1 root root 129178 15. Nov 16:31 libz.a $ m68k-atari-mint-size -t libpng16.a libz.a ... 237620 0 0 237620 3a034 (TOTALS) Both were compiled using gcc 7.5.0 Maybe you missed some optimizations? >Maybe +libz +libm as I didn't use any floating point before? Even with libz that should not add 800k. libm could add a few bytes, but that shouldn't be much, since, IIRC, only the gamma functions in libpng make use of doubles. |
|
From: Markus F. <ma...@mu...> - 2024-02-11 12:21:30
|
My libpng16.a is about 350K and it's indeed compiled against libcmini. But you are right, it's strange that linking differently can save 150K more than that. There must be something else going on additionally. Maybe +libz +libm as I didn't use any floating point before? Am Sonntag, dem 11.02.2024 um 12:02 +0100 schrieb Thorsten Otto: > On Samstag, 10. Februar 2024 22:42:29 CET Markus Fröschle wrote: > > adding png loading blew > > up program size from about 50K to > 1MB using the m68k-atari-mint > > 4.6.4 > > toolchain (using libcmini already, so no mintlib overhead). > > That is something i dont quite understand. Libpng (+libz which is > inevitable also needed) should be ~240K of code, even if everything > is linked in (which should not be the case when you only read png > files). > > Also note that it might be a bad idea to use libcmini & libpng in the > same application, unless you recompiled libpng with the libcmini > headers, since the FILE structure is completely different. > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Markus F. <ma...@mu...> - 2024-02-11 12:14:16
|
Am Sonntag, dem 11.02.2024 um 12:16 +0100 schrieb Miro Kropáček: > On Sun, 11 Feb 2024 at 08:49, Markus Fröschle <ma...@mu...> wrote: > > LTO was still enabled, but it doesn't actually help much (around > > 10K only) if you don't compile the library with the said switches. > > > > Since you have it all set up, could you please try it without LTO and > with the same switches? Just to rule out that the magical size > decrease required LTO *and* -Wl,--gc-sections. > That's what I tried already. Library is compiled without -flto (for the same reasons Thorsten pointed out) and -flto to the program alone makes a difference of less than 10K only. So yes, the main savings come from -ffunction/data-sections and --gc- sections. > -- > http://mikro.atari.org > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Miro K. <mir...@gm...> - 2024-02-11 11:17:26
|
On Sun, 11 Feb 2024 at 08:49, Markus Fröschle <ma...@mu...> wrote: > LTO was still enabled, but it doesn't actually help much (around 10K only) > if you don't compile the library with the said switches. Since you have it all set up, could you please try it without LTO and with the same switches? Just to rule out that the magical size decrease required LTO *and* -Wl,--gc-sections. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-02-11 11:03:02
|
On Samstag, 10. Februar 2024 22:42:29 CET Markus Fröschle wrote: >adding png loading blew >up program size from about 50K to > 1MB using the m68k-atari-mint 4.6.4 >toolchain (using libcmini already, so no mintlib overhead). That is something i dont quite understand. Libpng (+libz which is inevitable also needed) should be ~240K of code, even if everything is linked in (which should not be the case when you only read png files). Also note that it might be a bad idea to use libcmini & libpng in the same application, unless you recompiled libpng with the libcmini headers, since the FILE structure is completely different. |
|
From: Thorsten O. <ad...@th...> - 2024-02-11 09:17:03
|
On Sonntag, 11. Februar 2024 08:48:53 CET Markus Fröschle wrote: > LTO was still enabled, but it doesn't actually help much (around 10K > only) if you don't compile the library with the said switches. In the first versions of my mintelf toolchains, i also used LTO to compile the libraries. But there are some problems with this. First of, it makes the libraries huge (you have to put both the compiled code and the intermediate GIMPLE code in the object files to make it available to the linker). Secondly, the linking step takes a long time and lots of memory (several GB), because essentially, the whole library is recompiled in the linking step. But what is really annoying is, that the LTO format is incompatible between different major gcc versions. You cannot use libraries compiled by e.g. gcc 7.5 and link them with gcc 13. That would require to provide different libraries for different major gcc versions (currently there are 8 of them). So when i found that out, i dropped that approach and recompiled the libraries without lto. You can still use LTO however to compile the code of your application. For EmuTOS for example, that will save a few KB. Once the "official" mintelf toolchains are out, i will also recompile all libraries on my site using -ffunction-sections and -fdata-sections. But you will still have to adjust your Makefiles to use -Wl,--gc-sections to make really use of it. Note that you can use that switch regardless whether you are using the old a.out toolchains or the new mintelf toolchains. |
|
From: Markus F. <ma...@mu...> - 2024-02-11 07:49:10
|
Am Samstag, dem 10.02.2024 um 23:28 +0100 schrieb Miro Kropáček: > On Sat, 10 Feb 2024 at 22:56, Markus Fröschle <ma...@mu...> wrote: > > That reduced overall program size by a formidable 500K (!) to 399K. > > > > Was this still the LTO enabled? When I first learned about those > switches, I tried them too but with far less success: I tried ScummVM > (heavy C++, millions line of code) and Led Blur (simple C demo), both > of them stayed at the same size basically, even slightly larger. > LTO was still enabled, but it doesn't actually help much (around 10K only) if you don't compile the library with the said switches. > So maybe your case was really an extreme, i.e. linking and using a > lib where most of the functions are never touched. Sure. But that's not uncommon when you port applications from platforms that are mainly using shared libs and don't care much about program size. Just compile current ssh and it's over 4 Meg easily, for example. I didn't try (yet), but I'm sure you could bring that down significantly with this technique. One could as well say you won't get the full benefit of m68k-atari- mintelf if you don't compile your libs with these switches. |
|
From: Miro K. <mir...@gm...> - 2024-02-10 22:28:24
|
On Sat, 10 Feb 2024 at 22:56, Markus Fröschle <ma...@mu...> wrote: > That reduced overall program size by a formidable 500K (!) to 399K. > Was this still the LTO enabled? When I first learned about those switches, I tried them too but with far less success: I tried ScummVM (heavy C++, millions line of code) and Led Blur (simple C demo), both of them stayed at the same size basically, even slightly larger. So maybe your case was really an extreme, i.e. linking and using a lib where most of the functions are never touched. -- http://mikro.atari.org |
|
From: Markus F. <ma...@mu...> - 2024-02-10 21:55:46
|
Hi all, I'm currently experimenting with Vincent's m68k-atari-mintelf toolchain. I do have a "playground" program https://github.com/mfro0/libcmini-examples/tree/master/bench that doesn't do anything useful than showing some animated graphics in GEM windows. Originally meant as a libcmini example GEM program, I still use that to play around. I recently added a functionality to load and display png graphics that uses the png16 library cross compiled for MiNT. Adding png loading blew up program size from about 50K to > 1MB using the m68k-atari-mint 4.6.4 toolchain (using libcmini already, so no mintlib overhead). Compiling the exact same program using the mintelf compiler brought the program size down by nearly 150K to about 900K. Linking using LTO brought an additional reduction of only a few bytes. Today I recompiled the libpng16 library using -ffunction-sections -fdata-sections compiler options and linked the final executable with - Wl,--gc-sections. That reduced overall program size by a formidable 500K (!) to 399K. -ffunction-sections -fdata-sections for compilation and -Wl,--gc-sections should probably considered as default options for mintelf compilation (especially for ported Linux programs that use libraries that do not follow the old m68k-atari-mint "one function per file only" rule). Thanks to all the guys who made the m68k-atari-mintelf gcc toolchain possible! Cheers, Markus |
5 messages has been excluded from this view by a project administrator.
