Cornelius@SUMEX-AIM.STANFORD.EDU (Craig Cornelius) (11/20/87)
I'm writing a network interface (TCP/IP) for a program (written in C for an IRIS 3020) that also does graphics display. The idea is that the program will accept a connection over the net, check the connection for commands, and then interpret the commands and change the display appropriately. In an early version of this, Bruce Duncan of our lab had the display responding to mouse positions and other commands from a Xerox 11XX LISP workstation. The problem: SELECT is a graphics routine. There is also a SELECT routine for determining in a network message has been received. I want to use both! Does SGI have a solution to this problem? Has anyone else developed a work-around? Our initial solution was to use IOCTL to use the network connection as if it were a stream from a terminal, but this is really hacky and not at all in the spirit of network interfacing. Comments and suggestions are welcome. Craig Cornelius -------
sd%chem@SDCSVAX.UCSD.EDU (Steve Dempsey) (11/21/87)
SGI has changed the name of their graphics library routine 'select' to 'gselect' to take care of this problem. This change was effective with the 3.5 software release. See pages 4-39 and 4-40 of the release notes for details. The 'select' name is still in the graphics library, so in order to get the BSD call you have to make sure the BSD library precedes the graphics library in the loader command, as in: cc prog.c -lbsd -Zg
mike@BRL.ARPA.UUCP (11/21/87)
In the case of the BRL CAD Package, we make a privage copy of
/usr/lib/libdbm.a and /usr/lib/libgl2.a, delete select.o,
then add libbsd.a. This, and other vendor-specific brain-damage,
means that the MAKE rule for libfb.a (our device-independent
framebuffer library) look like this:
# On the Silicon Graphics (and in the future perhaps others),
# include the vendor's library within our own, so that linking
# with libfb.a is sufficient to make pictures.
#
${PRODUCTS}: $(OBJS)
-if test x${SYSVERS} = xSGI34 ; then \
rm -fr tmp; mkdir tmp; rm -f ${PRODUCTS}; cd tmp; \
${AR} x /usr/lib/libsocket.a; \
${AR} uv ../${PRODUCTS} *; \
rm -f *; \
${AR} x /usr/lib/libgl2.a; \
${AR} uv ../${PRODUCTS} *; \
cd ..; rm -fr tmp; \
fi
-if test x${SYSVERS} = xSGI35 ; then \
rm -fr tmp; mkdir tmp; rm -f ${PRODUCTS}; cd tmp; \
${AR} x /usr/lib/libdbm.a; \
${AR} x /usr/lib/libgl2.a; \
rm -f select.o; \
${AR} x /usr/lib/libbsd.a; \
${AR} uv ../${PRODUCTS} *; \
cd ..; rm -fr tmp ; \
fi
-if test x${SYSVERS} = xUNICOS20 ; then \
cp /usr/lib/libnet.${ARCH_SUF} ${PRODUCTS}; \
fi
-if test x${SYSVERS} = xSUN3 ; then \
rm -fr tmp; mkdir tmp; rm -f ${PRODUCTS}; cd tmp; \
${AR} x /usr/lib/libsuntool.a; \
${AR} x /usr/lib/libsunwindow.a; \
${AR} x /usr/lib/libpixrect.a; \
${AR} uv ../${PRODUCTS} *; \
cd ..; rm -fr tmp; \
fi
${AR} uv ${PRODUCTS} ${OBJS}
${RANLIB} ${PRODUCTS}
Also, note that I consider a vendor providing a library with
"unqualified" named as hopelessly naive. What body of user software for
doing graphics does not already have subroutines called "move", "draw",
etc? I had to modify hundreds of lines of code in our CAD Package to
permit linking with GL2 at all. Things should have been called
gl2_select(), as a minimum. I understand that in the dim dark days of
older versions of the eternally wonderful and unchanging SystemV
standard, CC was unable to handle symbols that were the same in the
first 8 characters. Sun scores better in this regard, typically with
4-letter prefixes, and wonderfully long and obtuse function names.
Of course, ADA (boo) and C++ handle this problem in a more powerful way.
Best,
-Mike