Forums

An SDCC 4.2.0 release is expected in February. For those of you that want to use 4.2.0, now is a last chance to check if there are any issues affecting you that could still be fixed before the release.

Major changes vs. 4.1.0:

* C23 memset_explicit
* Support for --oldralloc has been removed from the z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends.
* gbz80 port now uses more efficient block-initalization of global variables (users of custom a crt0 need to adapt theirs).
* Full support for __z88dk_callee for the z80, z180, gbz80, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka, stm8 backends.
* Support for __raisonance, __iar and __cosmic calling conventions for stm8.
* Support for a new __sdcccall(1) calling convention in the stm8 port AS NEW DEFAULT.
* Support for a new __sdcccall(1) calling convention in the gbz80 port AS NEW DEFAULT.
* Support for a new __sdcccall(1) calling convention in the z80, z80n and z180 ports AS NEW DEFAULT.
* Support for a new __sdcccall(1) calling convention in the r2k, r2ka, r3k, tlcs90 and ez80_z80 ports.
* Removed support for --profile for gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends.
* The z80n port Z80N Core minimum version has been raised from 1.0 to 2.0.
* Improved rematerialization support in the stm8, gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends.
* The gbz80 port was renamed to sm83.
* New in-development mos6502 port.

Philipp
(SDCC 4.2.0 release manager)

Thanks. Please make sure to provide a Linux build that can run on any distribution that is still supported, without forcing users to build their own binaries because of a missing useless dependency (as it happens with all the snapshot releases since some time)...

$ ./sdcc -v
./sdcc: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./sdcc)
./sdcc: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./sdcc)

sverx wrote

Thanks. Please make sure to provide a Linux build that can run on any distribution that is still supported, without forcing users to build their own binaries because of a missing useless dependency (as it happens with all the snapshot releases since some time)...

I don't think we can do this for 4.2.0. Maybe we can put a machine (virtual or real) with an old OS into the compile farm later (for snapshots and 4.3.0).

Thanks, I hope so.

I still can't understand why you guys think it's acceptable to distribute official release binaries that won't run on so many widespread major Linux distribution - you wouldn't release a binary for Windows that runs on Windows 11 only and just tell every Windows 8 or Windows 10 user to go compile the sources themselves, or would you?

sverx wrote

Thanks, I hope so.

I still can't understand why you guys think it's acceptable to distribute official release binaries that won't run on so many widespread major Linux distribution - you wouldn't release a binary for Windows that runs on Windows 11 only and just tell every Windows 8 or Windows 10 user to go compile the sources themselves, or would you?

While I hope we won't have to do that (after all Windows binaries are substantially more important than GNU/Linux ones for the release¹), if we don't have the resources we might have to in the future, if the alternative is to delay the release for months otherwise.

In fact, the Windows binaries often don't get as much testing as I wish they would. Our automated testing tests them on Wine only. In the last few days, SDCC developers did manual testing on Windows 10 and ReactOS. I wanted to test on Windows 7, too, but it looks like Microsoft has taken down some Windows 7 update servers, so a fresh install of Windows 7 now can't be updated.

Philipp

¹ Windows is an important platform for our users, and binaries are the standard way of distributing software for Windows. Since building software for Windows is a bit more involved, having source only would be a major inconvenience to many of our Windows users.
GNU/Linux is an important platform for our users, too. But binaries are not the common way of distributing software for it. By far the large majority of GNU/Linux users use either the packages from their distribution, or build SDCC from source. And the latter is easy:

./configure; make; make install

If any dependencies are missing, the build process will tell the user what they are. So not having binaries for some GNU/Linux systems is only a minor inconvenience to a small fraction of users.
For more exotic OSes, e.g. FreeBSD on aarch64, we don't even bother to have binaries in the release (we do have such a system in the build farm, and thus get snapshot binaries - but their purpose isn't really as a service for our users, but rather for SDCC developers to check that SDCC works on that system).

I might be a spoiled modern Linux user, but I rarely have to compile source code myself nowadays. Much of the software I use (not in official repositories) it's either in ppa repositories or distributed in deb packages or flatpaks.

Said that, I don't want to go on with this topic, as I will end up sounding ungrateful, and I want you to know instead that I appreciate your work and everything you provide [for free!] to us.

sverx wrote

Much of the software I use (not in official repositories) it's either in ppa repositories or distributed in deb packages or flatpaks.

Debian has sometimes skipped an SDCC version, but never two. Their current package is at 4.0.0, so I hope they'll package 4.2.0, so I'll think we'll see that .deb.

Release Candidate 1 for 4.2.0 has been prepared. Source, documentation and binary packages for amd64 GNU/Linux, 32 and 64 bit Windows and amd64 macOS are available in corresponding folders at the usual place:

http://sourceforge.net/projects/sdcc/files/

SDCC 4.2.0 has been released today.

I've just downloaded 4.2.0 and am mega grateful for your work on this. I can't wait to open it up and take it for a test run.

Author	Message
PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	SDCC 4.2.0 to be released in February Posted: Thu Feb 10, 2022 4:46 pm Last edited by PkK on Thu Feb 10, 2022 10:34 pm; edited 1 time in total
	An SDCC 4.2.0 release is expected in February. For those of you that want to use 4.2.0, now is a last chance to check if there are any issues affecting you that could still be fixed before the release. Major changes vs. 4.1.0: * C23 memset_explicit * Support for --oldralloc has been removed from the z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends. * gbz80 port now uses more efficient block-initalization of global variables (users of custom a crt0 need to adapt theirs). * Full support for __z88dk_callee for the z80, z180, gbz80, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka, stm8 backends. * Support for __raisonance, __iar and __cosmic calling conventions for stm8. * Support for a new __sdcccall(1) calling convention in the stm8 port AS NEW DEFAULT. * Support for a new __sdcccall(1) calling convention in the gbz80 port AS NEW DEFAULT. * Support for a new __sdcccall(1) calling convention in the z80, z80n and z180 ports AS NEW DEFAULT. * Support for a new __sdcccall(1) calling convention in the r2k, r2ka, r3k, tlcs90 and ez80_z80 ports. * Removed support for --profile for gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends. * The z80n port Z80N Core minimum version has been raised from 1.0 to 2.0. * Improved rematerialization support in the stm8, gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends. * The gbz80 port was renamed to sm83. * New in-development mos6502 port. Philipp (SDCC 4.2.0 release manager)

sverx Joined: 05 Sep 2013 Posts: 3823 Location: Stockholm, Sweden	Posted: Thu Feb 10, 2022 6:14 pm
	Thanks. Please make sure to provide a Linux build that can run on any distribution that is still supported, without forcing users to build their own binaries because of a missing useless dependency (as it happens with all the snapshot releases since some time)... $ ./sdcc -v ./sdcc: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./sdcc) ./sdcc: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./sdcc)

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Fri Feb 11, 2022 1:11 pm
	sverx wrote Thanks. Please make sure to provide a Linux build that can run on any distribution that is still supported, without forcing users to build their own binaries because of a missing useless dependency (as it happens with all the snapshot releases since some time)... I don't think we can do this for 4.2.0. Maybe we can put a machine (virtual or real) with an old OS into the compile farm later (for snapshots and 4.3.0).

sverx Joined: 05 Sep 2013 Posts: 3823 Location: Stockholm, Sweden	Posted: Fri Feb 11, 2022 2:52 pm
	Thanks, I hope so. I still can't understand why you guys think it's acceptable to distribute official release binaries that won't run on so many widespread major Linux distribution - you wouldn't release a binary for Windows that runs on Windows 11 only and just tell every Windows 8 or Windows 10 user to go compile the sources themselves, or would you?

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Sun Feb 13, 2022 10:24 am
	sverx wrote Thanks, I hope so. I still can't understand why you guys think it's acceptable to distribute official release binaries that won't run on so many widespread major Linux distribution - you wouldn't release a binary for Windows that runs on Windows 11 only and just tell every Windows 8 or Windows 10 user to go compile the sources themselves, or would you? While I hope we won't have to do that (after all Windows binaries are substantially more important than GNU/Linux ones for the release¹), if we don't have the resources we might have to in the future, if the alternative is to delay the release for months otherwise. In fact, the Windows binaries often don't get as much testing as I wish they would. Our automated testing tests them on Wine only. In the last few days, SDCC developers did manual testing on Windows 10 and ReactOS. I wanted to test on Windows 7, too, but it looks like Microsoft has taken down some Windows 7 update servers, so a fresh install of Windows 7 now can't be updated. Philipp ¹ Windows is an important platform for our users, and binaries are the standard way of distributing software for Windows. Since building software for Windows is a bit more involved, having source only would be a major inconvenience to many of our Windows users. GNU/Linux is an important platform for our users, too. But binaries are not the common way of distributing software for it. By far the large majority of GNU/Linux users use either the packages from their distribution, or build SDCC from source. And the latter is easy: ./configure; make; make install If any dependencies are missing, the build process will tell the user what they are. So not having binaries for some GNU/Linux systems is only a minor inconvenience to a small fraction of users. For more exotic OSes, e.g. FreeBSD on aarch64, we don't even bother to have binaries in the release (we do have such a system in the build farm, and thus get snapshot binaries - but their purpose isn't really as a service for our users, but rather for SDCC developers to check that SDCC works on that system).

sverx Joined: 05 Sep 2013 Posts: 3823 Location: Stockholm, Sweden	Posted: Tue Feb 15, 2022 2:36 pm
	I might be a spoiled modern Linux user, but I rarely have to compile source code myself nowadays. Much of the software I use (not in official repositories) it's either in ppa repositories or distributed in deb packages or flatpaks. Said that, I don't want to go on with this topic, as I will end up sounding ungrateful, and I want you to know instead that I appreciate your work and everything you provide [for free!] to us.

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Wed Feb 16, 2022 12:24 pm
	sverx wrote Much of the software I use (not in official repositories) it's either in ppa repositories or distributed in deb packages or flatpaks. Debian has sometimes skipped an SDCC version, but never two. Their current package is at 4.0.0, so I hope they'll package 4.2.0, so I'll think we'll see that .deb.

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Tue Feb 22, 2022 8:42 pm
	Release Candidate 1 for 4.2.0 has been prepared. Source, documentation and binary packages for amd64 GNU/Linux, 32 and 64 bit Windows and amd64 macOS are available in corresponding folders at the usual place: http://sourceforge.net/projects/sdcc/files/

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Tue Mar 08, 2022 7:42 am
	SDCC 4.2.0 has been released today.

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	Posted: Mon Mar 21, 2022 4:39 pm
	I've just downloaded 4.2.0 and am mega grateful for your work on this. I can't wait to open it up and take it for a test run.

Forums

View topic - SDCC 4.2.0 to be released in February