Workaround libncurses.so as a linker script

[nevans]

This maybe isn't probably isn't the best approach, but it should allow
Fiddle::Terminfo.curses_dl to work. I documented more details about
this in an issue on fiddle: ruby/fiddle#107

It is probably better to deal with it there. But this workaround is
simpler.

FYI: reline itself seems to be working just fine for me without
loading ncurses. But I wanted to be able to use Reline::Terminfo for
my own projects. :)

[st0012]

After this is merged, many downstream libs' CI hangs now (see #449). Since it's a workaround + the fiddle change has been made, I think we should revert this change. Wdyt? @hsbt

[hsbt]

I'm not sure why it's only stuck with Ruby 3.0 and 3.1.

@st0012 If you detect the root cause of this stuck, I'll revert this.

[st0012]

I think it's because the list is only loaded when fiddle_supports_variadic is true

https://github.com/ruby/reline/blob/master/lib/reline/terminfo.rb#L49

Which is set when Ruby is >= 3.0

reline/lib/reline/terminfo.rb

Lines 35 to 38 in 4347e4f

	if RUBY_VERSION >= '3.0.0'
	# Gem module isn't defined in test-all of the Ruby repository, and
	# Fiddle in Ruby 3.0.0 or later supports Fiddle::TYPE_VARIADIC.
	fiddle_supports_variadic = true

And #451 also proves that reverting this will fix the issue.

[hsbt]

Should we only add versioning so files into Ruby < 3.0?

[st0012]

Based on fiddle's final implementation and other gems', I don't think loading fixed versioning so files is the best option, regardless the Ruby version.

And as @nevans suggested, the proper way to fix ruby/fiddle#107 is to support linker script in fiddle. This workaround only bypasses fiddle's dlopen logic by specifying a fixed value that works for his environment.

So IMO, this PR should not be accepted in the first place, at least not without the CI result.

[hsbt]

Is there a solution for the environment that has only fixed versions of curses?

I hope to help that users.

[st0012]

I think that's what this fiddle commit does?

When having trouble reading libncurses.so, it'll

• Check if it's linker script related error
• Check if there's an INPUT or GROUP command like: INPUT(libncurses.so.6 -ltinfo)
• If there is, it loads libncurses.so.6 instead

[hsbt]

So IMO, this PR should not be accepted in the first place, at least not without the CI result.

OK, I revert this. But I was frustrated that you only focused on resolving the downstream repos. I'm happy to resolve the root cause in the next time.

[st0012]

I'm sorry that you feel that way. I'm actually using docker to debug the issue locally.

I think it needs to be reverted urgently because it's been breaking downstream repo CIs for over 2 weeks. And it's hard to trace the cause from those repos (I spent 2 days debugging ruby/debug just to found it's not its issue), nor is there any workaround for it.

[st0012]

Here's what I found about the CI hanging issue:

• Without this workaround, reline fails to find the .so file on CI
• When it does find the .so file, however, it changes the terminal output. For example:
  • With the change:

          from /home/runner/work
  /reline/reline/test/reline/yam
  atanooroti/multiline_repl:5:in
   `<main>'
  ^P
  

  • Without the change:

  :a
  Multiline REPL.
  prompt> :a
  => :a
  prompt> :a
  

• Because the yamatanooroti test framework waits for certain output to start, it hangs when the output changes. Furthermore, since it doesn't have a timeout mechanism, it waits forever.

I think this workaround does work, but reline and/or yamatanooroti aren't prepared for the behavior change introduced by loading libncurses.so.6.

[nevans]

It seems to me that the best place to handle linker resolution is fiddle, so reverting it seems reasonable to me.

But, if this is failing because it succeeds in loading libncurses.so.6, then I'm guessing it will start to fail again as soon as ruby/fiddle@49ea149 is released in the next version of fiddle. So whatever is causing CI incompatibility with libncurses.so.6 should probably be figured out before then! 🙂

[st0012]

I used docker to run irb with libncurses.so.6 and I didn't see any difference:

With your patch

irb(main):001:0>  Reline::Terminfo.curses_dl_files
=> ["libncursesw.so", "libcursesw.so", "libncurses.so", "libcurses.so", "libncursesw.so.6", "libncurses.so.6"]
irb(main):002:0>  Reline::Terminfo.curses_dl
=> #<Fiddle::Handle:0x0000ffff803ef8e8>
irb(main):003:0> ls _
Fiddle::Handle#methods: []  close  close_enabled?  disable_close  enable_close  file_name  sym  to_i  to_ptr
=> nil
irb(main):004:0>  Reline::Terminfo.curses_dl.file_name
=> "/lib/aarch64-linux-gnu/libncursesw.so.6"
irb(main):005:0> exit

With latest fiddle

irb(main):001:0> Fiddle.dlopen "libncurses.so" # fixed #dlopen
=> #<Fiddle::Handle:0x0000ffffafe434c8>
irb(main):002:0> exit

@nevans I assume you also didn't see any issue with it, otherwise you'd have reported it?
So I guess the problem is more likely on yamatanooroti.