vampyre@milton.u.washington.edu (Eric Michael Howard) (06/07/91)
Hi, I'm attempting to compile/install andrew on a sparc 1+, OS 4.1.1, with both X windows and Openwindows running. (X11R4, Openwindows 2.0) So for I haven't had any luck. The first run ended in atkams with a segmentation violation and then a core dump. I've since tried rebuilding and everytime I do so, it reaches a certain point and just hangs without giving any sort of error message. The last time I ran it, it stopped after: cc -c -I. -I/home/andrew/include/ams -O -I/home/andrew/include/atk -I ...stuff deleted... text822.c /home/andrew/include/site.h: 3: DEFAULT_ANDREWDIR_ENV redefined /home/andrew/bin/makedo -d /home/andrew/lib -b /home/andrew/bin -o text822.do\ text822.o Where I had done a make Clean and then a make World to get to this stage. The things that were set up different from the default are: DEFAULT_ANDREWDIR/ENV = /home/andrew AFSBASEDIR = /home/andy (but I don't believe this gets used) IMAKE =(X-tree)/config/imake XMAKEDEPEND = (X-Tree)/util/makedepend/makedepend RESOLVELIB = /usr/lib/libresolv.a (is this right? the file does exist, but I wasn't sure.) And I think that was it. Has anyone seen this problem and/or have a fix for it? Also, is there some sort of 'frequently asked questions list' that I should be looking in? If there is , could someone post me a copy? I only found this list yesterday. Thanks, eric vampyre@milton.u.washington.edu ehwd@uorpas.bitnet
guy@auspex.auspex.com (Guy Harris) (06/21/91)
>RESOLVELIB is kind of broken on SunOS 4.1 and 4.1.1. >It seems to have a funny format which upsets dynamic loading. Actually, it may depend on whose dynamic loading you're talking about. :-) The 4.1 "libresolv.a" appears to be filled with position-independent ".o" files; while that may mean they contain relocation directives that ATK's private dynamic linker can't cope with, it means that the dynamic linker built into SunOS 4.x may actually like them *better*, because they don't require relocation. I.e., the intent was that the "libresolv.a" stuff could be put into a modified "libc.so.X.Y" that, instead of using NIS to look up host names, used the resolver, so that dynamically-linked programs would magically start using the resolver. You *could* link with "-lresolv" - as I assume is done, in effect, with ATK programs - but I don't think that was the primary way Sun expected it to be used. When patch 10 comes out, this problem may go away, as ATK's private dynamic loader isn't used for ".do" files in patch 10 under 4.1[.x]; instead, "doload()" is built atop the routines in "-ldl" (present in SunOS 4.1[.x], SVR4, and perhaps in 4.4BSD).