Re: lynx-dev Mouse support on the console?

[Klaus Weide]

On Mon, 17 Jan 2000, Morten Bo Johansen wrote:

> T.E.Dickey <address@hidden> said:
> 
> > and ncurses was configured with gpm?
> >     configure --with-gpm

This is the most important question...

> I don't know - it is the precompiled stock SuSE 6.2 version.

My /usr/lib/libcurses.so is from the regular Debian package (4.2-3):

$ nm -D /usr/lib/libcurses.so|grep -i gpm
$

In other words, no gpm support.

This is a self-compiled version (5.0beta-ish - but the version difference
shouldn't matter)

$ nm -D /usr/local/lib/libcurses.so|grep -i gpm
         U Gpm_GetEvent
         U Gpm_Open
000157c0 T _nc_set_gpm_connect
         U gpm_fd
$

(I messed around with the source code in lib_mouse.c [an never finished and
wrapped-up attempt to improve something...] so what you'll see with a regular
library will be different... but the main point is still valid, which is
ncurses compiled with --with-gpm => references to gpm functions show up.)

> I'm a little
> wary of messing around with it since SuSE depends heavily on ncurses - even
> the bash shell relies on it so if I uninstall it to install another version
> my system will be disfunctional. Maybe you can suggest a safe procedure here?

Doing that may be the only way to go - if the library is compiled
without gpm support.  From my experience with Debian, I suspect that's
the normal way distributions combile the library.  (Well, the sample
size is a bit small...)

If you are careful, you can compile a lib version under /usr/local that
doesn't get in the way of the "vendor's" version.  (Make backup copies
of the original files if you're cautious, at least before the "make install"
step(s) of ncurses.)

Or recompile the SuSE package from sources - I don't know for sure about
SuSE, but every reasonable (non-minimal) linux distribution should allow that
easily - with the addition of --with-gpm as the only change.  You will need
the sources for ncurses *and* libgpm installed, or rather for libgpm the -dev
package (if SuSE does things similar to Debian...).

If you are paranoid about bash freaking out while you are messing around,
temporarily use a different shell... make sure you can at least re-instate
the regular lib{n,}curses.so.* files to the original state from that shell
(cp,mv,ln,ldconfig should all work - they shouldn't be linked to ncurses)
if something really goes wrong.

Oh yeah - you may *also* have to re-generate your libgpm library (or
make a local version for it, too).  (That's to prevent a situation,
when you now have two shared ncurses libs, where lynx => new libcurses
in /usr/local => libgpm => old libcurses.  The '=>' is the one from
ldd output.  [Oh, you should also check ldd to check library
dependencies.]  That would be Bad.  But I think it only applies if the
sonames [basically, the numbers after the lib{n,}curses.so.] are
different between the versions.)

And find the right magic to pass -I and -L flags to the lynx build
process.  And (if if you recompile libgpm) to that earlier
compilation, too.  And then set environment variable LD_LIBRARY_PATH
before starting lynx... (depends on whether both versions [if you now
have two] have the same so numbers.)

I hope I didn't scare you off.  Good luck...

> Can I check - as with nm or strings - is my version of ncurses was indeed
> compiled with gpm support?

See above (I don't know why I need to use -D to check dynamic symbols while
you apparently don't... may be a version-of-binutils thing).

> > The lynx configure script is supposed to test if it must use -lncurses 
> > -lgpm,
> > so that's another check.
> 
> This is a snippet from the config.log. There is a failure notice at the end
> which may have something to do with it..?

I assume that's just an expected failure - for a test using an ncurses
function without -lcurses.

   Klaus