Colors: The native method "COLOR_PAIRS" does not exist

[psantosl]

Hey,

Just got

The native method "COLOR_PAIRS" does not exist

Trying to run a sample app (https://github.com/psantosl/htopsharp) in OpenSuse Leap 15.1 freshly installed.

[psantosl]

I do have /lib64/libncursesw.so.5 on my system

and

nm -D /lib64/libncursesw.so.5 | grep COLOR
000000000000fb70 T COLOR_PAIR
0000000000232434 B COLOR_PAIRS
0000000000232430 B COLORS

[psantosl]

Ok, the problem is that it probably tries to load libncursesw.so.6 instead

 nm -D /lib64/libncursesw.so.5 | grep COLOR
000000000000fb70 T COLOR_PAIR
0000000000232434 B COLOR_PAIRS
0000000000232430 B COLORS
pablo@linux-pablo:~/wkspaces/htopsharp> nm -D /lib64/libncursesw.so.6 | grep COLOR
0000000000011110 T COLOR_PAIR
000000000000f120 T _nc_COLOR_PAIRS
000000000000f140 T _nc_COLORS

[psantosl]

It works if I try to load "libncursesw.so.5" before so.6 in bindings.cs...

I tried to load the equivalent methods, but failed to locate the so.6 equivalent for LINES

[tig]

Is this still an issue? If not, please close it.

[migueldeicaza]

I think we should make it so we probe _nc_COLOR_PARIS and _nc_COLORS first, and if we fail, we fallback to COLOR_PAIR, COLOR_PAIRS.

[migueldeicaza]

Honestly - the long term solution is to avoid curses at all.

Curses is so often miss-compiled, so often old, so often compiled with missing capabilities, and with semantics that I end up working around more often than I wish.

The main case for ncurses is the optimization code that can compute the best commands to compute the area of the screen to update, but that is no longer a hard problem, and the speed of terminals is faster than it used to be.

Since I have recently completed two terminal emulators, I think that ncurses is really working against fully leveraging the capabilities of an xterm (what most things implement now).

So I would love to build a new backend that does not rely on all these bad hacks (like even colors today are highly limited because of the space, or high colors do not work properly on Mac, again, because it is compiled without all capabilities)

[migueldeicaza]

haha, I knew I had written something about it:

#370

[psantosl]

Hey! But the new backend is not ready to use, right?

I only had issues in opensuse so far. Couple of cloud servers in amazon and google went well :-)

[tig]

This is covered by #370. Closing.

[adam8797]

Do we have a workaround for this? Looks like v2 is a long way off yet.

[tig]

I dunno. But I'm reopening as my closing it was clearly in error.

Maybe another contributor more familiar with Linux can help!

[BDisp]

Do we have a workaround for this? Looks like v2 is a long way off yet.

CursesDriver uses the COLOR_PAIRS if I'm not wrong. Can you be more specific about the issue to try to help, please.

[adam8797]

Sure, I commented because I'm having the exact same problem as @psantosl was having.

On the target system, I have both libncursesw.so.5 and libncursesw.so.6.

When the application loads, it chooses libncursesw.so.6 which doesn't have the COLOR_PAIRS function defined

[BDisp]

Sure, I commented because I'm having the exact same problem as @psantosl was having.

On the target system, I have both libncursesw.so.5 and libncursesw.so.6.

When the application loads, it chooses libncursesw.so.6 which doesn't have the COLOR_PAIRS function defined

Thanks for the explanation. But this is happening with all the Linux system or only with some specific version? What do you suggest? If exist both libncursesw* only loads the libncursesw.so.5? This may cause issue for the users who want using libncursesw.so.6. What colors system the libncursesw.so.6 is using? Perhaps true color with rgb color which Terminal.Gui doesn't support yet.

Another workaround is use the NetDriver by setting the Application.UseSystemConsole = true before call Application.Init().

[tznind]

@adam8797 do you know the steps to get these .so files on your target? Did they ship with the distro or was there a package/packages that were added that then broke Terminal.Gui? For example installing or updating the nucurses package from command line.

@BDisp I don't know exactly how the binding / locating of libraries is happening in CursesDriver but it might be possible to probe the ones that are found and decide whether they are a compatible version (have the required methods). If a dll or so file doesn't have a required method from our API and theres an alternative one available on the machine that does have the required methods then we should probably at least try to use that one?

If the .so files are found automatically by the OS then having them in the same location as the binary you are running may make it bind to them? worth trying anyway (or just use --usc as @BDisp suggests).

[adam8797]

I actually don't have that level of control on these machines, they were built and managed by others. They're running SLES (an OpenSuSE variant) so that seems to be the common thread here, as the original post was on OpenSuSE Leap

I'll try setting the UseSystemConsole option and report back

[tznind]

Its a good idea to make Application.UseSystemConsole = true a user setting from CLI (or config file). That empowers users as there can be advantages/drawbacks depending on environment and remoting tech (SSH / Guacamole etc)

[adam8797]

@BDisp looks like you found the workaround!

Application.UseSystemConsole = true;
Application.Init();

Seems to work in this situation.

I can probably rely on this in my case (as all of the target machines are the same), but more generally a workaround could be to look for the libncursesw.so.6 file, and/or take an argument.

Thanks for everyone's help, hopefully this edge case can be remediated in the library proper.

[adam8797]

@tznind are there any drawbacks to setting Application.UseSystemConsole = true?

[BDisp]

@BDisp I don't know exactly how the binding / locating of libraries is happening in CursesDriver but it might be possible to probe the ones that are found and decide whether they are a compatible version (have the required methods). If a dll or so file doesn't have a required method from our API and theres an alternative one available on the machine that does have the required methods then we should probably at least try to use that one?

That checks are made in the binding.cs file. But as @migueldeicaza said in #415 (comment) comment we can't rely totally on ncurses.

[BDisp]

This is the information in the WSL Ubuntu distro with the correct values in the libncursesw.so.6. The libncursesw.so.5 doesn't exist.

~$ nm -D /usr/lib/x86_64-linux-gnu/libncursesw.so.6 | grep COLOR
0000000000039030 B COLORS
000000000000f4c0 T COLOR_PAIR
0000000000039034 B COLOR_PAIRS

[adam8797]

Weird, maybe the OpenSuSE family of products just has a different/bad version of libncursesw.so:

$ nm -D /lib64/libncursesw.so.6 | grep COLOR
0000000000010990 T COLOR_PAIR
000000000000f020 T _nc_COLOR_PAIRS
000000000000f040 T _nc_COLORS

[BDisp]

Yes probably they don't compile the ncurses source with all the options.

[tznind]

@tznind are there any drawbacks to setting Application.UseSystemConsole = true?

In my experience UseSystemConsole is usually better in linux. But at one point it was much slower on Windows (although I think that was fixed). I think it just depends really, there are so many different configurations and technologies and remoting tech like SSH clients or Guacamole add another level of complexity. Basically it switches which ConsoleDriver is used so being able to control that at runtime is often useful for wider support.

Another thing that sometimes is an issue is the $TERM variable (e.g. see #2085)

But I don't think I've seen any environments where it won't work with some permutation of $TERM and/or UseSystemConsole. I've even had it running on the lite install of Raspbian (see #1697).

[BDisp]

But I don't think I've seen any environments where it won't work with some permutation of $TERM and/or UseSystemConsole. I've even had it running on the lite install of Raspbian (see #1697).

The $TERM environment is needed with NetDriver to get the mouse moves in Linux.

[BDisp]

Opensuse doesn't work with the libncurses6 and the workaround is install the libncurses5 (with the command sudo zypper install libncurses5) and Terminal.Gui will load it at run.

[BDisp]

Reopening this to submit another PR with a different approach to fix it.