Commit https://src.fedoraproject.org/rpms/ncurses/c/e9317e9 removed support for ncurses-compat-libs (i.e. ncurses5). I cannot run the bare metal toolchain from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads without this package: $ ./gcc-arm-11.2-2022.02-x86_64-arm-none-eabi/bin/arm-none-eabi-gdb ./gcc-arm-11.2-2022.02-x86_64-arm-none-eabi/bin/arm-none-eabi-gdb: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory My older toolchain $ arm-none-eabi-gdb arm-none-eabi-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory I'm not the only person to report this issue https://www.reddit.com/r/Fedora/comments/ygl7zy/can_we_bring_back_ncursescompatlibs_in_fedora_37/ https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CKAQH23MRZBBRYQCY2TXBRU6XCBHSIIQ/ this topic was brought up on the list with the question of whether packages outside of Fedora should be considered. I do think the answer is yes. The Fedora community has a history of putting in work which appropriate to make 3rd party packages work. Fedora does provide a minimal cross toolchain but it leaves some parts out (for good reasons!), hence my need to use a separate download. I can certainly compile the libs myself but it's much easier when Fedora provides it. If the package can't be brought back it would be good to provide an explanation why for future reference and so that 3rd party developers know what they need to do to be compatible.
Yes, please we need this as well for this package and for few other non Fedora packages we use. I understood that it was removed, quote"I didn't see any dependencies on libtinfo.so.5, or libncurses/w.so.5 in the repository". But many users use software that is not in the standard Fedora repository. For now I will try and build a ncurses-compat-libs package for our use as we can't use Fedora37 without this.
Created attachment 1929636 [details] ncurses spec file with ncuses-compat-libs build
For those that need ncurses-compat-libs for Fedora37 I have built this at: https://portal.beam.ltd.uk/dist/fedora_37/beamExtra/x86_64/packages/ncurses-compat-libs-6.3-3.20220501.fc37.x86_64.rpm the spec file for this was just attached.
Is there a newer version of the toolchain you could use? Is it still maintained? I don't think Fedora is or should be trying to support every ancient binary that exists. Generally, old libraries are dropped as soon as nothing is using them in Fedora. The ncurses ABI 5 compat package was kept in Fedora for 7 years. How long would you like it to be? 20 years?
Not that I know of that also works for us, and we have past tool chains we use for older projects and it's not list this ARM development toolchain there are a few other packages we use for various FPGA/embedded processor work that requires this older libncurses 5 lib. libncurses is used in quite a few software packages and is one of those basic libraries that software uses, so is a relatively core library IMO. Redhat7 uses ncurses5 and a lot of generic Linux packages are based/built on that system as it it pretty generic/stable and most software built for it will run on other Linux systems. Personally I think libncurses 5 should stay as a compat while it is still needed for packages that are reasonably still in use and while Redhat7 is still a widely used system. We are actually using software packages built 21 years ago, on Fedora35 :)
Can you please try it with libncurses.so.5 -> libncurses.so.6 and/or libtinfo.so.5 -> libtinfo.so.6 symlinks? So far, I think everything that was reported for this issue only needed the terminfo functions, no an actual ncurses application. If that doesn't work I'd suggest using a container, which has the required versions of libraries.
I really don't want to be cross symbolic linking to a newer API library, who knows what that will do with some of the programs we use. The last thing I want to do is introduce containers especially as the proper fix is simple. If Fedora doesn't provide the necessary system support for my usage as an OS, then I will just use my own override RPM's to provide the missing functionality, as I am now doing. Personally although I know Fedora is a bit of a frontier system, as it is fundamentally an OS to allow people to run programs to do their work I think it should support as many programs people might use as reasonably possible and certainly those that external and commercial developers produce for Redhat7 where this is easily possible.
You want the latest greatest that Fedora has, but at the same time expect that ancient binaries will continue to work and not willing to implement any workarounds. As I understand it, that is not a goal of Fedora. You can suggest it on the devel list or maybe ask FESCo for guidance. *** This bug has been marked as a duplicate of bug 2129865 ***
No all I suggest is that a compat library be re-instated that was dropped in Fedora37. I have implemented a workaround, I created the compat RPM that I am now using, I am just trying to help others that will be in the same boat and help make Fedora better. Thanks for your work with Fedora, from your knowledge is there some issue with keeping the compat RPM (it was simple to add the necessary bits back in the spec file) ? Actually is there some policy on retiring compat libs or supporting older packages on Fedora that I can refer to when posting my opinions in the devel list ? By the way, IMO, "latest and greatest" is most often not the greatest :)
AFAIK there is no written policy. I asked on the devel list, but there was no response. The practice seems to be that compat packages are removed when no longer needed by other Fedora packages. The issue with keeping the ncurses compat package is that it makes the maintenance more difficult (more complicated spec), the build takes more time, and the extra packages grow repodata and waste space on mirrors.
This is pretty disappointing to (In reply to Miroslav Lichvar from comment #4) > Is there a newer version of the toolchain you could use? Is it still > maintained? > > I don't think Fedora is or should be trying to support every ancient binary > that exists. Generally, old libraries are dropped as soon as nothing is > using them in Fedora. > https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads these are all new gcc releases that came out in 2022. The example I gave was built in February 2022 and is the last stable update. So yes, there are in fact new releases coming out that are still using the older ncurses ABI. I am going to file a ticket with FESCO as suggested. This seems like something that should have been discussed via the self contained change process https://docs.fedoraproject.org/en-US/program_management/changes_policy/ to make sure everyone is on the same page with Fedora policy and goals.
(In reply to Laura Abbott from comment #11) > https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads these are > all new gcc releases that came out in 2022. The example I gave was built in > February 2022 and is the last stable update. So yes, there are in fact new > releases coming out that are still using the older ncurses ABI. Which older ncurses ABI exactly do they need? The default upstream before 5.5, default post 5.5, the one that was in Fedora and RHEL, or some other distribution? It's not like there was just one ABI 5. There were options that different distributions set differently and I think this was one of the main reasons why ABI 6 was introduced, which seems to work better except that symbol versioning. When we find old applications using different ABI 5 variants, should we add more compat packages?
Looks to me that this change is hurting our Fedora users, for little gain. Just because nothing in Fedora Linux itself needs the older library doesn't mean it is not important. There seems to be enough demand for the old SONAME. (The author of ghcup just approached me asking if Fedora 37 had really dropped ncurses-compat-libs...)