rhtvision links against X11

What a mess.

We use rhtvision to provide a X-less installer and routines.

I just discovered the unimaginable:

/usr/local/lib/librhtv.so.2:
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x281a3000)
	libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x2825f000)
	libncurses.so.5 => /usr/lib/libncurses.so.5 (0x28274000)
	libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x282b5000)
	libm.so.2 => /usr/lib/libm.so.2 (0x282fa000)
	libc.so.4 => /usr/lib/libc.so.4 (0x28069000)
	libXThrStub.so.6 => /usr/X11R6/lib/libXThrStub.so.6 (0x28315000)
	libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x28317000)
	libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x28361000)
	libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x2836a000)
	libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x28380000)

rhtvision seems to require X. Yay. That sucks.

I've explored rhtvision's example programs a bit, and they have a X11
driver *by default*. That means they popup a X-window and don't
display in the terminal you called them in if DISPLAY is set.

These demos, by the way, work pretty well *except* in TTY mode. In a
tty, they just *ignore* any input, apparently, so rhtvision is just
plain borked, in FreeBSD, at least.

And to make things even worse, this doesn't even fix the compilation
issue. Liking against X and all those libs when linking the text build
doesn't help much.

I'm still trying to figure out if it's possible to build a X-less
rhtvision under FreeBSD and have it work. If not, we'll have to port
tvision to GCC 3.x, or scrap the tvision approach altogether and turn
to another text mode backend. DlDialog, maybe?

A.

-- 
Computer science is no more about computers
than astronomy is about telescopes
                        - E. Dijkstra

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE9tNmottcWHAnWiGcRAtBmAJ9kN+lhcURpG8+gnhlIVxFt4aI22wCfQW+8
4DT5q1gB1uIIMqZGTnRANpo=
=OfQi
-----END PGP SIGNATURE-----