This is what one person had to do to get Tk working on some SVR4 machines. I would appreciate knowing if this is generic to SVR4, or if these machines are particularly obscure. Nick. From owner-ptk@WPI.EDU Thu Jul 27 21:13:26 1995 Return-Path: Message-Id: From: mgm@holos.com (Martha Armour) Subject: Yet Another SVR4 Update To: ptk@WPI.EDU Date: Thu, 27 Jul 1995 16:12:08 -0400 (EDT) Cc: perl5-porters@nicoh.com Reply-To: mgm@holos.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3791 Sender: owner-ptk@WPI.EDU Precedence: bulk P-From: mgm@holos.com (Martha Armour) Tk-b5 is finally working on both of my SVR4 platforms. After much gnashing of my teeth and pulling of my hair, I turned my problems over to a co-worker. His trials, tribulations and successes follow: The following was written by Len Reed : I've been fooling with Tk on three platforms: (A) AT&T GIS (formerly NCR) SVR4. uname gives "4.0 3.0 3360,3430-R 386/486/MC" This is a 3430 Microchannel machine. It uses the "Metaware" compiler. (L) Linux (a.out executables), kernel version 1.2.5. Uses gcc. (M) Motorola 88k SVR4 Unix, uname gives "4.0 R40V4.2 m88k mc88100" This machine came from Motorola with gcc (named cc). I'm using perl5.001m and Tk-b5. (L) worked fine. Both SVR4 machines--(A) and (M)--built perl fine. I used the [svr4] hints: note that the ucb stuff was therefore included. Minor SVR4 troubles ------------------ Both SVR4 systems required changes to Tk-b5/pTk/tkPort.h due to conflicts between Tk-provided prototypes and the system headers. I removed tkPort.h's gettimeofday and TclOpen prototypes. (Since open() is defined as TclOpen, the TclOpen prototype conflicts the the system open() prototype: the latter uses ... for the 3rd parameter.) The (M) machine exhibited a weird problem generating position independent code. Perl detected that this was gcc and tried to use -fpic. That was pretty well ignored in the perl build. Then, the Tk build turned this into -fPIC. The -f was ignored, and -P became "run the preprocessor." I ended up forcing perl to use -kPIC, which worked fine for both perl and Tk. Major SVR4 troubles ------------------- Both SVR4 systems had trouble with dynamic linking. Specifically, they could not find XOpenDisplay(). This was traced to the dlopen semantics. The dlopen(3X) manual says that "objects loaded by a single ... dlopen may .. not directly reference symobls from objects loaded by a different dlopen." The Tk module could not find the Xwindows stuff. When I added -lX11 to the perl link command and rebuilt perl, the Xwindows library worked fine. Additional AT&T (NCR) troubles ------------------------------ The AT&T machine (A) had two additional problems, both of which were hell to find. Tk basic_demo script opens "/dev/tty" and the passes it to an event handler. On the AT&T machine, it appears that select (actually its poll at the kernel interface level) won't work if one of the descriptors is /dev/tty. It returned an error (ENXIO) and Tk went into a loop. No mouse or keyboard input was accepted. Interestingly, opening `tty`, which gave the name of the pseudo tty for my xterm, worked fine. I'm guessing that this is a bug in the /dev/tty driver. After fixing that, basic_demo (and other perl Tk scripts) worked fine on the console but not on other X servers. I discovered that XOpenDisplay() was hanging up on everything except the console. Even setting DISPLAY to something like "nosuchmachine:0" would lock it up. The fix was to remove -lnet from the perl link command. The /usr/lib/libnet.so library appears to contain something that really messes XOpenDisplay(): a trivial C program that did nothing but call XOpenDisplay() was the key to putting the blame on libnet.so. After taking -lnet out of perl's list of libraries, I found that Tk could not find strcasecmp, which oddly enough was in libnet.so. I then added -lresolv to perl's list--not to Tk's, mind you, for the same reason that -lX11 had to been in perl's list. Anyway, libresolv.so gave me strcasecmp. I dunno how much use any of this is to someone not on a GIS machine. Let me (lbr@holos.com) know if you'd like more info leading to easing installation on this GIS/NCR machine. --- End of Len's comments --- -- Martha G. Armour Holos Software, Inc. Atlanta, Georgia USA mgm@holos.com