Skip to content

Conversation

@jpc-lip6
Copy link
Contributor

The backward compatibility code for <termio.h> has been removed starting from GLIBC 2.42. So it starts to fail on some bleeding edge distributions like openSUSE Tumbleweed. We took back the code removed from the GLIBC and put it back inside txInput.c.

The backward compatibility code for <termio.h> has been removed starting
from GLIBC 2.42. So it starts to fail on some bleeding edge distributions
like openSUSE Tumbleweed. We took back the code removed from the GLIBC
and put it back inside txInput.c.
@RTimothyEdwards
Copy link
Owner

Thanks for the input!

@dlmiles : You have a good understanding of OS compatibility issues. Any comment on the GLIBC changes?

@dlmiles
Copy link
Collaborator

dlmiles commented Jan 15, 2026

@jpc-lip6 Please see this issue and comment #435 (comment)

There is a commit listed in this comment, please apply this and see if it resolves your build issue.

Adding a private copy of struct termio (to manage a compiler error) is not a step forwards.

The commit is a better approach as it, reduces lines of code, cleans up the proliferation of the header file, it should still work in theory (we have no CI to test) on systems that have one of the two legacy termios methods (termio.h/sgtty.h) which different platforms converted to termios.h in different ways.

Can you please at least cite the make -k build errors seen, to convey what you are seeing. i.e. describe the original problem from your situation than only describing what you think the solution is. The XY problem of communication.
All POSIX systems have temios.h and it is the new (since 1988) and current method, all other methods are considered obsolete and relate to legacy historical operating system versions (before 1988, which are not supported or maintained by this project, because those systems no longer have receive updates/fixes at the o/s and system level and have no CI available and limited users).

@jpc-lip6
Copy link
Contributor Author

I confirm that your commit #435 works with the GLIBC 2.42.

When encountering those kind of deprecation problems, we have two ways of solving it:

  • The quick way, when feasible and when you are not too familiar with the code you are patching, is to embed the compatibility code (as long as it stands).
  • The best way, is to upgrade the code to newer standard. Which may incur a lot of work.

The question here may be why it was not merged into trunk ?

Yes, next time I will provides the build log.

My builds, and their logs can be found here : https://build.opensuse.org/package/show/home:jpc-lip6/magic

(the faulty one are no longer there after I made the correction).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants