From owner-ogl-sample@oss.sgi.com Thu Jun 1 04:38:20 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 04:38:10 -0700 Received: from inspire.inspirepharm.com ([208.223.172.2]:65297 "EHLO inspire.inspirepharm.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 04:37:51 -0700 Received: from gusty (firewall.inspirepharm.com [10.0.0.1]) by inspire.inspirepharm.com (8.10.0/8.10.0) with SMTP id e51BZ1A19441 for ; Thu, 1 Jun 2000 07:35:01 -0400 From: "Suhaib Siddiqi" To: Subject: [ogl-sample] How to compile OGL SI on Windows using Cygwin Date: Thu, 1 Jun 2000 08:38:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002D_01BFCBA4.C36F4E70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_002D_01BFCBA4.C36F4E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I posted this a while ago on Cygwin/XFree mailing list. Users on this mailing list may be interested to: Suhaib ---------------------------- 1) Down download patched XFRee86 4.0 source tree from Cygwin/XFree URL http://sourceware.cygnus.com/cygwin/xfree 2) Retrieve SGI OpenGL code from SGI CVS at http://oss.sgi.com/projects 3) Follow the Instructions in the README file of OpenGL code to merge the code into XFree86 source tree. 4) change the include/make/commondefs file with the attached file. Since it is only 12 K I am posting here. 5) Compile using make World. Go get a cup of coffee!!! compiling whole XFRee86 Source tree with OpenGL will take time. ------=_NextPart_000_002D_01BFCBA4.C36F4E70 Content-Type: application/octet-stream; name="commondefs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="commondefs" # License Applicability. Except to the extent portions of this file are=0A= # made subject to an alternative license as permitted in the SGI Free=0A= # Software License B, Version 1.0 (the "License"), the contents of this=0A= # file are subject only to the provisions of the License. You may not use=0A= # this file except in compliance with the License. You may obtain a copy=0A= # of the License at Silicon Graphics, Inc., attn: Legal Services, 1600=0A= # Amphitheatre Parkway, Mountain View, CA 94043-1351, or at:=0A= # =0A= # http://oss.sgi.com/projects/FreeB=0A= # =0A= # Note that, as provided in the License, the Software is distributed on = an=0A= # "AS IS" basis, with ALL EXPRESS AND IMPLIED WARRANTIES AND CONDITIONS=0A= # DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES AND=0A= # CONDITIONS OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A=0A= # PARTICULAR PURPOSE, AND NON-INFRINGEMENT.=0A= # =0A= # Original Code. The Original Code is: OpenGL Sample Implementation,=0A= # Version 1.2.1, released January 26, 2000, developed by Silicon = Graphics,=0A= # Inc. The Original Code is Copyright (c) 1991-2000 Silicon Graphics, = Inc.=0A= # Copyright in any portions created by third parties is as indicated=0A= # elsewhere herein. All Rights Reserved.=0A= # =0A= # Additional Notice Provisions: The application programming interfaces=0A= # established by SGI in conjunction with the Original Code are The=0A= # OpenGL(R) Graphics System: A Specification (Version 1.2.1), released=0A= # April 1, 1999; The OpenGL(R) Graphics System Utility Library (Version=0A= # 1.3), released November 4, 1998; and OpenGL(R) Graphics with the X=0A= # Window System(R) (Version 1.3), released October 19, 1998. This = software=0A= # was created using the OpenGL(R) version 1.2.1 Sample Implementation=0A= # published by SGI, but has not been independently verified as being=0A= # compliant with the OpenGL(R) version 1.2.1 Specification.=0A= #=0A= # $Date$ $Revision$=0A= # $Header: //depot/main/tools/include/commondefs#39 $=0A= =0A= COMMONRULES=3D$(ROOT)/usr/include/make/commonrules=0A= =0A= # what OS are we running on=0A= OS=3D$(shell uname)=0A= ifeq ($(subst 64,,$(OS)), IRIX)=0A= OS=3DIRIX=0A= endif=0A= =0A= # various source-level directories=0A= TOOLSSRC =3D $(TOPDIR)/tools=0A= GFXINCLUDESRC =3D $(TOPDIR)/gfx/include=0A= OGLLIBSRC =3D $(TOPDIR)/gfx/lib/opengl=0A= GLXLIBSRC =3D $(TOPDIR)/glx=0A= =0A= # shell-related defs=0A= SHELL =3D /bin/sh=0A= AWK =3D awk=0A= ECHO =3D /bin/echo=0A= RM =3D rm -f=0A= MV =3D mv=0A= PERL =3D perl=0A= SED =3D sed=0A= UNIQ =3D uniq=0A= =0A= # M4 options - run GNU M4 in compatibility mode=0A= # rdist options - Red Hat 5.2 must have daemon location specified=0A= ifeq ($(OS),IRIX)=0A= M4OPTS =3D=0A= endif=0A= ifeq ($(OS),Linux)=0A= M4OPTS =3D -G=0A= RDIST_OPTS =3D -p /usr/sbin/rdistd=0A= endif=0A= =0A= ifeq ($(OS),CYGWIN*)=0A= M4OPTS =3D -G=0A= RDIST_OPTS =3D=0A= endif=0A= =0A= =0A= # override default gmake CXX with what we have=0A= ifeq ($(OS),IRIX)=0A= CXX =3D CC=0A= endif=0A= =0A= # what language are we using? Default to ansi with extended defines=0A= ifeq ($(OS),IRIX)=0A= CVERSION =3D -xansi=0A= endif=0A= ifeq ($(OS),Linux)=0A= CVERSION=3D -ansi -include $(ROOT)/usr/include/make/linuxdefs=0A= endif=0A= =0A= ifeq ($(OS),CYGWIN*)=0A= CXX =3D g++=0A= CVERSION=3D -ansi -include $(ROOT)/usr/include/make/linuxdefs=0A= endif=0A= =0A= =0A= # WARN is the warning option=0A= ifeq ($(OS),IRIX)=0A= #=0A= # Turn of explicitly some warnings on IRIX. Specifically:=0A= # 1155: unrecognized #pragma=0A= # 1174: parameter/variable "???" was declared but never referenced=0A= # 1201: trailing comma is nonstandard (last element in struct assnment)=0A= # 1209: controlling expression is constant=0A= # 1506: implicit conversion from "???" to "???": rounding, sign =0A= # extension, or loss of accuracy may result=0A= # 3170: "???" not marked as intrinsic because it is not declared =0A= # as a function=0A= #=0A= WARN =3D -fullwarn \=0A= -woff 1155,1174,1506,1201,1209,3170=0A= endif=0A= ifeq ($(OS),Linux)=0A= WARN =3D -Wimplicit \=0A= -Wreturn-type \=0A= -Wswitch \=0A= -Wcomment \=0A= -Wformat \=0A= -Wchar-subscripts \=0A= -Wparentheses \=0A= -Wpointer-arith \=0A= -Wcast-qual \=0A= -Wmissing-prototypes \=0A= -Wmissing-declarations \=0A= $(NULL)=0A= endif=0A= =0A= ifeq ($(OS),CYGWIN*)=0A= WARN =3D -Wimplicit \=0A= -Wreturn-type \=0A= -Wswitch \=0A= -Wcomment \=0A= -Wformat \=0A= -Wchar-subscripts \=0A= -Wparentheses \=0A= -Wpointer-arith \=0A= -Wcast-qual \=0A= -Wmissing-prototypes \=0A= -Wmissing-declarations \=0A= $(NULL)=0A= endif=0A= =0A= =0A= # default optimization=0A= ifeq ($(subst y,1,$(GLDEBUG)),1)=0A= OPTIMIZER=3D-g=0A= else=0A= OPTIMIZER=3D-O2=0A= ifeq ($(OS),Linux)=0A= WARN +=3D -Wuninitialized=0A= ifeq ($(OS),CYGWIN*)=0A= WARN +=3D -Wuninitialized=0A= endif=0A= endif=0A= endif=0A= =0A= # how to make dependencies=0A= ifeq ($(OS),IRIX)=0A= MKDEPOPT =3D -MDupdate Makedepend=0A= endif=0A= ifeq ($(OS),Linux)=0A= MKDEPOPT =3D -MD=0A= endif=0A= =0A= ifeq ($(OS),CYGWIN*)=0A= MKDEPOPT =3D -MD=0A= endif=0A= =0A= =0A= override GCOPTS =3D $(OPTIMIZER) $(MKDEPOPT) $(WARN)=0A= override GCXXOPTS =3D $(OPTIMIZER) $(MKDEPOPT) $(WARN)=0A= =0A= # where is the default include directory?=0A= # (we don't grab it off $ROOT, to avoid populating $ROOT with system=0A= # includes. Yes, I know... You don't like the idea.=0A= INCLDIR =3D /usr/include=0A= =0A= # where to install include files?=0A= INCLUDE_LOCATION =3D $(ROOT)/usr/include=0A= =0A= # we would like to use nostdinc on Linux, but unfortunately, it also=0A= # removes include directories with no well-known fixed path (ie. the=0A= # gcc install directory).=0A= ifeq ($(OS),IRIX)=0A= override GCINCS =3D -nostdinc -I$(ROOT)$(INCLDIR) -I$(INCLDIR)=0A= override GCXXINCS =3D -nostdinc -I$(ROOT)$(INCLDIR) -I$(INCLDIR)=0A= endif=0A= ifeq ($(OS),Linux)=0A= override GCINCS =3D -I$(ROOT)$(INCLDIR)=0A= override GCXXINCS =3D -I$(ROOT)$(INCLDIR) -I$(INCLDIR)=0A= endif=0A= =0A= ifeq ($(GLDEBUG),1)=0A= override GCDEFS =3D -DDEBUG -UNDEBUG=0A= override GCXXDEFS =3D -DDEBUG -UNDEBUG=0A= else=0A= override GCDEFS =3D -UDEBUG -DNDEBUG=0A= override GCXXDEFS =3D -UDEBUG -DNDEBUG=0A= endif=0A= =0A= #=0A= # Cc flags, composed of:=0A= # variable (V*) (set on the command line)=0A= # local (L*) (set in the makefile)=0A= # global (G*) (defined in this file, not overrideable)=0A= # in that order. This is done so that the locally defined includes=0A= # are searched before the globally defined ones.=0A= #=0A= CFLAGS =3D $(CVERSION) $(VCFLAGS) $(LCFLAGS) $(GCFLAGS)=0A= =0A= #=0A= # Each of these three components is divided into defines (-D's and -U's),=0A= # includes (-I's), and other options. By segregating the different=0A= # classes of flag to cc, the defines (CDEFS) and includes (CINCS) can be=0A= # easily given to other programs, e.g., lint.=0A= #=0A= # Notes:=0A= # - The local assignments should be to LCOPTS, LCDEFS, and LCINCS, not = to=0A= # LCFLAGS, although CFLAGS will be correctly set if this is done.=0A= # - If a program cannot be optimized, it should override the setting of=0A= # OPTIMIZER with a line such as "OPTIMIZER=3D" in its make file.=0A= # - If a program cannot be compiled with ANSI C, its makefile=0A= # should set CVERSION=3D-cckr=0A= #=0A= VCFLAGS =3D $(VCDEFS) $(VCINCS) $(VCOPTS)=0A= LCFLAGS =3D $(LCDEFS) $(LCINCS) $(LCOPTS)=0A= GCFLAGS =3D $(GCDEFS) $(GCINCS) $(GCOPTS)=0A= =0A= COPTS =3D $(VCOPTS) $(LCOPTS) $(GCOPTS)=0A= CDEFS =3D $(VCDEFS) $(LCDEFS) $(GCDEFS)=0A= CINCS =3D $(VCINCS) $(LCINCS) $(GCINCS)=0A= =0A= #=0A= # CXX flags are decomposed using the same hierarchy as C flags.=0A= #=0A= CXXFLAGS =3D $(CVERSION) $(VCXXFLAGS) $(LCXXFLAGS) $(GCXXFLAGS)=0A= =0A= VCXXFLAGS =3D $(VCXXDEFS) $(VCXXINCS) $(VCXXOPTS)=0A= LCXXFLAGS =3D $(LCXXDEFS) $(LCXXINCS) $(LCXXOPTS)=0A= GCXXFLAGS =3D $(GCXXDEFS) $(GCXXINCS) $(GCXXOPTS)=0A= =0A= CXXOPTS =3D $(VCXXOPTS) $(LCXXOPTS) $(GCXXOPTS)=0A= CXXDEFS =3D $(VCXXDEFS) $(LCXXDEFS) $(GCXXDEFS)=0A= CXXINCS =3D $(VCXXINCS) $(LCXXINCS) $(GCXXINCS)=0A= =0A= #=0A= # Do something for the linker=0A= #=0A= #=0A= # Library paths (-L's) are part of LDOPTS.=0A= # Libraries (-l's) are part of LDLIBS.=0A= # This is done so that there is a guarantee that all library paths are=0A= # included before the libraries.=0A= #=0A= override GLDOPTS=3D=0A= override GLDDSOOPTS=3D=0A= ifeq ($(OS),IRIX)=0A= override GLDOPTS +=3D -L$(ROOT)/usr/lib32=0A= override GLDDSOOPTS +=3D -L$(ROOT)/usr/lib32=0A= endif=0A= ifeq ($(OS),Linux)=0A= override GLDOPTS +=3D -L$(ROOT)/usr/lib -L$(XTOPDIR)/xc/exports/lib=0A= override GLDDSOOPTS +=3D -L$(ROOT)/usr/lib -L$(XTOPDIR)/xc/exports/lib=0A= endif=0A= ifeq ($(OS),CYGWIN)=0A= override GLDOPTS +=3D -L$(ROOT)/usr/lib -L$(XTOPDIR)/xc/exports/lib=0A= override GLDDSOOPTS +=3D -L$(ROOT)/usr/lib -L$(XTOPDIR)/xc/exports/lib=0A= endif=0A= =0A= =0A= # options used for DSO's.=0A= ifeq ($(OS),IRIX)=0A= DSONAMEOPT =3D -soname $(DSONAME)=0A= ifneq ($(DSOEXPORTS),)=0A= DSOEXPORTSOPT =3D -exports_file $(DSOEXPORTS)=0A= endif=0A= override GLDDSOOPTS +=3D -elf -shared -all $(DSOEXPORTSOPT) $(DSONAMEOPT)=0A= endif=0A= =0A= ifeq ($(OS),Linux)=0A= DSONAMEOPT =3D -soname=3D$(DSONAME)=0A= ifeq ($(OS),CYGWIN)=0A= DSONAMEOPT =3D -soname=3D$(DSONAME)=0A= ifneq ($(DSOEXPORTS),)=0A= DSOEXPORTSOPT =3D $(addprefix -u ,$(shell cat $(DSOEXPORTS)))=0A= else=0A= DSOEXPORTSOPT =3D --whole-archive=0A= endif=0A= override GLDDSOOPTS +=3D -shared $(DSOEXPORTSOPT) $(DSONAMEOPT)=0A= endif=0A= endif=0A= LDDSOOPTS =3D $(VLDDSOOPTS) $(LLDDSOOPTS) $(GLDDSOOPTS)=0A= LDDSOLIBS =3D $(VLDDSOLIBS) $(LLDDSOLIBS) $(GLDDSOLIBS)=0A= LDDSOFLAGS =3D $(LDDSOOPTS) $(LDDSOLIBS) $(ENDIAN)=0A= =0A= LDOPTS =3D $(VLDOPTS) $(LLDOPTS) $(GLDOPTS)=0A= LDLIBS =3D $(VLDLIBS) $(LLDLIBS) $(GLDLIBS)=0A= LDFLAGS =3D $(LDOPTS) $(LDLIBS) $(ENDIAN)=0A= =0A= # where to install libraries=0A= ifeq ($(OS),IRIX)=0A= OBJECT_STYLE =3D N32=0A= LIB_LOCATION =3D $(ROOT)/usr/lib32=0A= endif=0A= ifeq ($(OS),Linux)=0A= LIB_LOCATION =3D $(ROOT)/usr/lib=0A= endif=0A= =0A= #=0A= # as flags are just like cc flags.=0A= # By default, ASTYLE is the same as CSTYLE, but some may need to make=0A= # the asm more aggressive than 'C' and can set ASTYLE. Users of 'make'=0A= # always get ASTYLE =3D=3D CSTYLE=0A= #=0A= ASFLAGS =3D $(VASFLAGS) $(LASFLAGS) $(GASFLAGS)=0A= =0A= VASFLAGS =3D $(VASDEFS) $(VASINCS) $(VASOPTS)=0A= LASFLAGS =3D $(LASDEFS) $(LASINCS) $(LASOPTS)=0A= GASFLAGS =3D $(GASDEFS) $(GASINCS) $(GASOPTS)=0A= =0A= ASOPTS =3D $(VASOPTS) $(LASOPTS) $(GASOPTS)=0A= ASDEFS =3D $(VASDEFS) $(LASDEFS) $(GASDEFS)=0A= ASINCS =3D $(VASINCS) $(LASINCS) $(GASINCS)=0A= =0A= override GASOPTS =3D $(OPTIMIZER) $(MKDEPOPT)=0A= override GASDEFS =3D $(GCDEFS)=0A= override GASINCS =3D $(GCINCS)=0A= =0A= #=0A= # the install command to use=0A= #=0A= INSTALL =3D $(ROOT)/usr/bin/gfxinstall=0A= INSTALLFLAGS =3D -v -m 0444=0A= =0A= #=0A= # Convenient command macros that include the flags macros.=0A= #=0A= # You should always invoke make in makefiles via $(MAKE), as make passes=0A= # all command-line variables through the environment to sub-makes.=0A= #=0A= # Never use just $(CCF), etc. in rules that link executables; LDFLAGS=0A= # needs to be included after your objects in the command line.=0A= #=0A= ASF =3D $(AS) $(ASFLAGS)=0A= CXXF =3D $(CXX) $(CXXFLAGS)=0A= C++F =3D $(CXXF)=0A= CCF =3D $(CC) $(CFLAGS)=0A= LDF =3D $(LD) $(LDFLAGS)=0A= LEXF =3D $(LEX) $(LFLAGS)=0A= YACCF =3D $(YACC) $(YFLAGS)=0A= =0A= # Targets=0A= =0A= COMMONTARGS =3D clobber clean rmtargets=0A= =0A= ALLTARGS =3D headers headers_install libs libs_install install apps = distsi \=0A= $(COMMONTARGS)=0A= =0A= #=0A= # Rule macros for nonterminal makefiles that iterate over subdirectories,=0A= # making the current target. Set *SUBDIRS to the relevant list of kids.=0A= #=0A= # Set NOSUBMESG to any value to suppress a warning that subdirectories=0A= # are not present. This is useful with mandefs/rules=0A= #=0A= SUBDIR_MAKERULE=3D \=0A= if test ! -d $$d; then \=0A= if test "$(NOSUBMESG)" =3D "" ; then \=0A= echo "SKIPPING $$d: No such directory."; \=0A= fi \=0A= else \=0A= $(ECHO) "\t(cd $$d; $(MAKE) $${RULE:=3D$@})"; \=0A= (cd $$d; ${MAKE} $${RULE:=3D$@}); \=0A= fi=0A= =0A= SUBDIRS_MAKERULE=3D \=0A= @for d in $(SUBDIRS); do $(SUBDIR_MAKERULE); done=0A= =0A= #=0A= # One problem with the above rules is that if a make fails, and -k is=0A= # set, the entire for loop might stop. This is because make still can=0A= # (and XPG requires it) exit with an error status if the -k option is = set.=0A= # This is an alternate rule for SUBDIRS when it is desired that -k keep=0A= # working on the next SUBDIR if the previous one failed. Its not quite=0A= # as compact a rule as the previous ones.=0A= # A standard usage would be:=0A= # default install $(COMMONTARGS): $(_FORCE)=0A= # $(MAKE) __DORULE=3D$@ $(SUBDIRS)=0A= # $(SUBDIRS): $(_FORCE)=0A= # @$(NSUBDIR_MAKERULE)=0A= =0A= NSUBDIR_MAKERULE=3D \=0A= if test ! -d $@; then \=0A= if test "$(NOSUBMESG)" =3D "" ; then \=0A= echo "SKIPPING $@: No such directory."; \=0A= fi \=0A= else \=0A= echo "\t(cd $@; $(MAKE) $(__DORULE))"; \=0A= (cd $@; ${MAKE} $(__DORULE)); \=0A= fi=0A= =0A= #=0A= # Convenience file list macros:=0A= # - Commondefs defines the following lists: SOURCES, enumerating = all=0A= # source files; OBJECTS, the .o files derived from compilable = source;=0A= # and DIRT, which lists intermediates and temporary files to be=0A= # removed by clean.=0A= # - The including (parent) makefile may define source file lists = for=0A= # the standard suffixes: CFILES for .c, ASFILES for .s, YFILES = for=0A= # .y, etc. We combine all such lists into SOURCES. The = including=0A= # makefile need not define CFILES &c before including commondefs.=0A= #=0A= SOURCES=3D$(HFILES) $(ASFILES) $(CCFILES) $(C++FILES) $(CXXFILES) = $(CFILES) \=0A= $(EFILES) $(FFILES) $(LFILES) $(PFILES) $(RFILES) $(SHFILES) $(YFILES)=0A= =0A= CXXO1=3D$(CXXFILES:.c++=3D.o) $(C++FILES:.c++=3D.o) $(CCFILES:.c++=3D.o)=0A= CXXO2=3D$(CXXO1:.cxx=3D.o)=0A= CXXO3=3D$(CXXO2:.C=3D.o)=0A= CXXO4=3D$(CXXO3:.cc=3D.o)=0A= CXXOALL=3D$(CXXO4)=0A= YO1=3D$(YFILES:.y=3D.o)=0A= YO2=3D$(YO1:.yxx=3D.o)=0A= YO3=3D$(YO2:.Y=3D.o)=0A= YOALL=3D$(YO3)=0A= LO1=3D$(LFILES:.l=3D.o)=0A= LO2=3D$(LO1:.lxx=3D.o)=0A= LO3=3D$(LO2:.L=3D.o)=0A= LOALL=3D$(LO3)=0A= OBJECTS=3D$(ASFILES:.s=3D.o) $(CXXOALL) $(CFILES:.c=3D.o) = $(EFILES:.e=3D.o) \=0A= $(FFILES:.f=3D.o) $(LOALL) $(PFILES:.p=3D.o) $(RFILES:.r=3D.o) \=0A= $(YOALL)=0A= =0A= #=0A= # dependency file(s)=0A= #=0A= ifeq ($(OS),IRIX)=0A= MKDEPFILE =3D Makedepend=0A= endif=0A= ifeq ($(OS),Linux)=0A= MKDEPFILE =3D $(OBJECTS:.o=3D.d)=0A= endif=0A= =0A= ifeq ($(OS),CYGWIN*)=0A= MKDEPFILE =3D $(OBJECTS:.o=3D.d)=0A= endif=0A= =0A= #=0A= # distribution file=0A= #=0A= DISTFILE_EXT =3D Distfile=0A= DISTFILE_INT =3D Distfile.int=0A= DISTFILE =3D $(DISTFILE_EXT) $(DISTFILE_INT)=0A= =0A= =0A= #=0A= # dirt stuff=0A= #=0A= DIRT=3D$(GDIRT) $(VDIRT) $(LDIRT)=0A= override GDIRT=3D*.o a.out core lex.yy.[co] y.tab.[cho] ar.tmp.* = so_locations=0A= =0A= LOCALDEFS =3D ./localdefs=0A= LOCALRULES =3D ./localrules=0A= =0A= -include $(LOCALDEFS)=0A= ------=_NextPart_000_002D_01BFCBA4.C36F4E70-- From owner-ogl-sample@oss.sgi.com Fri Jun 2 20:02:53 2000 Received: by oss.sgi.com id ; Fri, 2 Jun 2000 20:02:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4647 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Jun 2000 20:02:26 -0700 Received: from torus.engr.sgi.com (torus.engr.sgi.com [130.62.52.219]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA09922 for ; Fri, 2 Jun 2000 21:07:15 -0700 (PDT) mail_from (skunk@sgi.com) Received: from localhost (skunk@localhost) by torus.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA06044 for ; Fri, 2 Jun 2000 20:59:44 -0700 (PDT) Date: Fri, 2 Jun 2000 20:59:44 -0700 From: "Daniel Richard G." X-Sender: skunk@torus.engr.sgi.com To: OpenGL SI list Subject: [ogl-sample] Future notes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hello everyone, I'm an intern, working in SGI's OpenGL group this summer. My job is to make good things happen with the Sample Implementation. I'll be active on this list, at least once I get up to speed on how everything works :-) Among the first things I'll work on: * The SI really needs a better build system. The current mode of setting environment variables and using GNU Make is kind of grotty, and not very portable. I'm thinking of migrating things over to autoconf and automake, to make things easier for everyone. The Imake stuff would remain, and of course building in the X tree will still be possible as now. Among other benefits, things like GLDEBUG and XTOPDIR would become configure script flags, and file-building/moving operations (e.g. exporting to the X tree) can be automated with minimal fuss. If anyone has thoughts on this, please send 'em in. This would involve a fair number of changes, and I want to make sure most of you want it. * I'll also be taking a whack at integrating the FBConfig/Pbuffer stuff (from the IRIXsoft GLX1.3 tree), so watch for activity in that area. If anyone has a really good grasp on that part of the tree, and would like to help this along, let me know! Serving SGI and the open source community, --Danny Daniel Richard G. SiliconGraphics - OpenGL Group From owner-ogl-sample@oss.sgi.com Mon Jun 5 07:51:42 2000 Received: by oss.sgi.com id ; Mon, 5 Jun 2000 07:51:30 -0700 Received: from callisto.acsu.buffalo.edu ([128.205.7.122]:33233 "HELO callisto.acsu.buffalo.edu") by oss.sgi.com with SMTP id ; Mon, 5 Jun 2000 07:40:10 -0700 Received: (qmail 12106 invoked from network); 5 Jun 2000 02:13:27 -0000 Received: from ubppp248-175.dialin.buffalo.edu (128.205.248.175) by callisto.acsu.buffalo.edu with SMTP; 5 Jun 2000 02:13:27 -0000 Date: Sun, 4 Jun 2000 22:16:05 -0400 (EDT) From: James Simmons X-Sender: jsimmons@maxwell.futurevision.com To: OpenGL SI list Subject: Re: [ogl-sample] Future notes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing > * The SI really needs a better build system. The current mode of setting > environment variables and using GNU Make is kind of grotty, and not very > portable. I'm thinking of migrating things over to autoconf and automake, > to make things easier for everyone. The Imake stuff would remain, and of > course building in the X tree will still be possible as now. Thank you!! Thank you!! I like to see OpenGL more environment independent. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsimmons@linux-fbdev.org] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net From owner-ogl-sample@oss.sgi.com Tue Jun 6 19:33:17 2000 Received: by oss.sgi.com id ; Tue, 6 Jun 2000 19:32:57 -0700 Received: from [202.101.11.210] ([202.101.11.210]:15958 "EHLO ns1.ubisoft.com.cn") by oss.sgi.com with ESMTP id ; Tue, 6 Jun 2000 19:32:28 -0700 Received: from mail.ubisoft.com.cn (exchsrv.ubisoft.com.cn [10.9.200.1]) by ns1.ubisoft.com.cn (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA13984 for ; Wed, 7 Jun 2000 11:05:25 +0800 Received: by exchsrv.ubisoft.com.cn with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 10:33:54 +0800 Message-ID: <1043D69C05E1D311AC8400A0C933B512B0E467@exchsrv.ubisoft.com.cn> From: Chen Gang To: ogl-sample@oss.sgi.com Subject: [ogl-sample] generated files Date: Wed, 7 Jun 2000 10:33:53 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Maybe because my RedHat 6.0 has not been setted correctly, I can not make SI successly, so only some files have been generated, like gl.h, glu.h..., but others failed. Here is my question : Could I download these generated files from somewhere ? Or someone could send me the generated files by a private mail? Personaly, I am not interesting in this messy generating tricks. We should keep life simple, right? Chen Gang From owner-ogl-sample@oss.sgi.com Wed Jun 21 23:26:51 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 23:26:42 -0700 Received: from [202.101.11.210] ([202.101.11.210]:26196 "EHLO ns1.ubisoft.com.cn") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 23:26:22 -0700 Received: from mail.ubisoft.com.cn (exchsrv.ubisoft.com.cn [10.9.200.1]) by ns1.ubisoft.com.cn (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA00614 for ; Thu, 22 Jun 2000 15:00:36 +0800 Received: by exchsrv.ubisoft.com.cn with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 14:27:36 +0800 Message-ID: <1043D69C05E1D311AC8400A0C933B512C96CC4@exchsrv.ubisoft.com.cn> From: Chen Gang To: ogl-sample@oss.sgi.com Subject: [ogl-sample] SI for Win32 Date: Thu, 22 Jun 2000 14:27:33 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hello all, Is this list still alive? After many rebootings from Linux to Win2000 (got only one machine at home), and many workarounds, and many switchs from watch euro2000 football match to study SI source codes, finally I made SI work on win2000! It looks great. I think maybe some people are interested in porting SI to win32 , and want study it on win32 too, and I remember that there is a "how to contribute" section in so doc(faq), so if anyone want to study it on win32, I would be glad to send a compressed source to him/her. Chen Gang From owner-ogl-sample@oss.sgi.com Tue Jun 27 06:50:23 2000 Received: by oss.sgi.com id ; Tue, 27 Jun 2000 06:50:14 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:29381 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Tue, 27 Jun 2000 06:49:54 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id PAA28628; Tue, 27 Jun 2000 15:49:42 +0200 (MET DST) Message-ID: <3958B3C4.2E659A4C@cyberbotics.com> Date: Tue, 27 Jun 2000 16:01:40 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.6-16apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@lists.sourceforge.net Subject: [ogl-sample] SGI SI GLU RPM packaging for Mesa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hello, After a discussion on the mesa3d-dev mailing list, it has been decided by Brian Paul to drop the Mesa GLU and use the SGI SI GLU instead: See the mailing list archive for reference: http://www.geocrawler.com/lists/3/SourceForge/1290/0/3943395/ http://www.geocrawler.com/lists/3/SourceForge/1290/0/3943052/ I am not sure we could simply merge SGI GLU within Mesa distribution (for license reasons). However, I would like to make it easy for end users to use Mesa together with SGI SI GLU. For this reason, I would like to build a couple of binary RPM packages. The first one would contain Mesa without its GLU and the second would contain SGI SI GLU only (that is libGLU.so and associated soft links and the glu.h header file). For this, it might be useful to add an RPM .spec file into the SGI GLU CVS. Maybe it could be even simpler for the end user to have a single binary RPM package containing both Mesa GL and SGI GLU, but I don't know if this is legally possible ? Could someone from SGI-OSS let me know his point of view about it ? Thank you. -Olivier From owner-ogl-sample@oss.sgi.com Wed Jun 28 07:10:22 2000 Received: by oss.sgi.com id ; Wed, 28 Jun 2000 07:10:12 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:21500 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Wed, 28 Jun 2000 07:09:54 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id QAA11097; Wed, 28 Jun 2000 16:09:18 +0200 (MET DST) Message-ID: <395A09DC.56D83324@cyberbotics.com> Date: Wed, 28 Jun 2000 16:21:16 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.6-16apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: mesa3d-dev@lists.sourceforge.net CC: ogl-sample@oss.sgi.com Subject: [ogl-sample] SGI SI GLU integration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hello, I wrote the ogl-sample-glu.spec RPM file to produce the RPM package for SGI SI GLU and everything seemed fine. I could build the ogl-sample-glu-20000126.i386.rpm file properly. I also built a mesa-without-glu-280600.i386.rpm for testing SGI SI GLU with mesa core GL. However, I had a couple of problems when trying to get it work: 1) The SGI glu.h file has some problem with Mesa gl.h file: a) The typedef void (*_GLfuncptr) defined in SGI gl.h but not in Mesa gl.h => idea: either add this typedef to Mesa gl.h, or use something different in SGI glu.h (like *_GLUfuncptr) b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are redefined in SGI glu.h (they are previously defined in Mesa gl.h) => idea: move them into SGI gl.h 2) The libGLU.so built from the GNUmakefile does not contain the C++ symbols like __pure_virtual. This is Ok if you link it with a C++ app, but it causes an undefined symbol when linking with C programs or libraries. I could work around this problem by linking by hand the libGLU.so using g++ instead of ld: g++ -shared -Wl,-soname,libGLU.so libutil/*.o libtess/*.o etc. Fixing this would require big change the GNUmakefile and included files in the ogl-sample package. I didn't do it because I was afraid of breaking other things (in the build of other libraries than GLU). Anyway, I did all that with the downloadable tarball of ogl-sample (ogl-sample-20000126.tgz) because I was unable to get the CVS source tree version (apparently, there is a broken link on the web page). Any help or advices greatly appreciated. -Olivier From owner-ogl-sample@oss.sgi.com Wed Jun 28 08:22:43 2000 Received: by oss.sgi.com id ; Wed, 28 Jun 2000 08:22:33 -0700 Received: from cmn2.cmn.net ([206.168.145.10]:50546 "EHLO cmn2.cmn.net") by oss.sgi.com with ESMTP id ; Wed, 28 Jun 2000 08:22:19 -0700 Received: from precisioninsight.com (jens2.cmn.net [207.174.125.34]) by cmn2.cmn.net (8.9.0/8.9.0) with ESMTP id JAA21560; Wed, 28 Jun 2000 09:21:55 -0600 Message-ID: <395A0A7D.F4A9F796@precisioninsight.com> Date: Wed, 28 Jun 2000 08:23:57 -0600 From: Brian Paul Organization: Precision Insight, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.3.51 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@lists.sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <395A09DC.56D83324@cyberbotics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Olivier Michel wrote: > > Hello, > > I wrote the ogl-sample-glu.spec RPM file to produce the RPM package for > SGI SI GLU and everything seemed fine. I could build the > ogl-sample-glu-20000126.i386.rpm file properly. > > I also built a mesa-without-glu-280600.i386.rpm for testing SGI SI GLU > with mesa core GL. > > However, I had a couple of problems when trying to get it work: > > 1) The SGI glu.h file has some problem with Mesa gl.h file: > > a) The typedef void (*_GLfuncptr) defined in SGI gl.h but not in Mesa > gl.h > => idea: either add this typedef to Mesa gl.h, > or use something different in SGI glu.h (like *_GLUfuncptr) My understanding was the _GLfuncptr was something added in order to make work the autogeneration of the header files from the spec files. It's supposed to be a private symbol. I like the idea of glu.h defining _GLUfuncptr if it needs it. > b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are > redefined in SGI glu.h (they are previously defined in Mesa gl.h) > => idea: move them into SGI gl.h glu.h should not define any GL_* tokens. Could you send me your glu.h file? > 2) The libGLU.so built from the GNUmakefile does not contain the C++ > symbols like __pure_virtual. This is Ok if you link it with a C++ app, > but it causes an undefined symbol when linking with C programs or > libraries. I could work around this problem by linking by hand the > libGLU.so using g++ instead of ld: > > g++ -shared -Wl,-soname,libGLU.so libutil/*.o libtess/*.o etc. > > Fixing this would require big change the GNUmakefile and included files > in the ogl-sample package. I didn't do it because I was afraid of > breaking other things (in the build of other libraries than GLU). When you build the libGLU.so shared library, could you add -lg++ (the C++ runtime lib) to the list of objects? That way, libGLU.so would be implicitly linked to libg++.so, so hopefully the end-user could use the regular gcc linker. > Anyway, I did all that with the downloadable tarball of ogl-sample > (ogl-sample-20000126.tgz) because I was unable to get the CVS source > tree version (apparently, there is a broken link on the web page). > > Any help or advices greatly appreciated. Here's how I get the ogl-sample CVS files: % cvs -d:pserver:cvs@oss.sgi.com:/cvs login password is cvs % cvs -d:pserver:cvs@oss.sgi.com:/cvs co projects/ogl-sample/main -Brian From owner-ogl-sample@oss.sgi.com Wed Jun 28 09:43:34 2000 Received: by oss.sgi.com id ; Wed, 28 Jun 2000 09:43:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:46196 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Jun 2000 09:43:14 -0700 Received: from arioch.engr.sgi.com (arioch.engr.sgi.com [130.62.54.161]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA10338 for ; Wed, 28 Jun 2000 09:38:24 -0700 (PDT) mail_from (shreiner@arioch.engr.sgi.com) Received: (from shreiner@localhost) by arioch.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA27285; Wed, 28 Jun 2000 09:41:50 -0700 (PDT) From: Dave Shreiner MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Jun 2000 09:41:50 -0700 (PDT) To: ogl-sample@oss.sgi.com Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration In-Reply-To: <395A0A7D.F4A9F796@precisioninsight.com> References: <395A09DC.56D83324@cyberbotics.com> <395A0A7D.F4A9F796@precisioninsight.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14682.10828.31749.420441@arioch.engr.sgi.com> Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Brian Paul writes: > Olivier Michel wrote: > > > b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are > > redefined in SGI glu.h (they are previously defined in Mesa gl.h) > > => idea: move them into SGI gl.h > > glu.h should not define any GL_* tokens. Could you send me your glu.h > file? I believe this situation is caused by an error in SGI's header generator script. I'll take a look at it. Thanx, Dave --------------------------------------------------------------------- Dave Shreiner Silicon Graphics, Inc. (650) 933-4899 From owner-ogl-sample@oss.sgi.com Wed Jun 28 13:33:58 2000 Received: by oss.sgi.com id ; Wed, 28 Jun 2000 13:33:39 -0700 Received: from adsl-63-204-9-35.dsl.snfc21.pacbell.net ([63.204.9.35]:40976 "EHLO bluevoid.com") by oss.sgi.com with ESMTP id ; Wed, 28 Jun 2000 13:33:21 -0700 Received: (from blythe@localhost) by bluevoid.com (8.9.3/8.9.3) id NAA17628 for ogl-sample@oss.sgi.com; Wed, 28 Jun 2000 13:33:20 -0700 Date: Wed, 28 Jun 2000 13:33:20 -0700 From: blythe@bluevoid.com Message-Id: <200006282033.NAA17628@bluevoid.com> To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] SGI SI GLU integration Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing | 2) The libGLU.so built from the GNUmakefile does not contain the C++ | symbols like __pure_virtual. This is Ok if you link it with a C++ app, | but it causes an undefined symbol when linking with C programs or | libraries. I could work around this problem by linking by hand the | libGLU.so using g++ instead of ld: | g++ -shared -Wl,-soname,libGLU.so libutil/*.o libtess/*.o etc. | | Fixing this would require big change the GNUmakefile and included files | in the ogl-sample package. I didn't do it because I was afraid of | breaking other things (in the build of other libraries than GLU). there was a fixed checked in to the tree a while ago (April), but no new tarball was created. I think a less intrusive change would be be something like: g++ -shared -Wl,-soname,libGLU.so -Wl,--whole-archive $(SRCLIBS) -Wl,--no-whole-archive -o $@ I've made a more portable version of this (diffs below) and will check it in later today (if no one objects) david | | Anyway, I did all that with the downloadable tarball of ogl-sample | (ogl-sample-20000126.tgz) because I was unable to get the CVS source | tree version (apparently, there is a broken link on the web page). | | Any help or advices greatly appreciated. Index: GNUmakefile =================================================================== RCS file: /home/pub/cvs/projects/ogl-sample/main/gfx/lib/glu/GNUmakefile,v retrieving revision 1.1 diff -r1.1 GNUmakefile 42c42 < TARGET = libGLU.so --- > TARGET = libGLU.so.1 48,49c48,51 < # There should be a cleaner, version-independent way to do this < LLDLIBS += -L/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66 -lstdc++ --- > # use g++ rather than ld > LD=g++ > LDDSOFLAGS=-shared -Wl,-soname=$(TARGET) -Wl,--whole-archive > LDFLAGS=-Wl,--no-whole-archive From owner-ogl-sample@oss.sgi.com Wed Jun 28 14:02:18 2000 Received: by oss.sgi.com id ; Wed, 28 Jun 2000 14:02:08 -0700 Received: from adsl-63-204-9-35.dsl.snfc21.pacbell.net ([63.204.9.35]:49168 "EHLO bluevoid.com") by oss.sgi.com with ESMTP id ; Wed, 28 Jun 2000 14:02:07 -0700 Received: (from blythe@localhost) by bluevoid.com (8.9.3/8.9.3) id OAA13880 for ogl-sample@oss.sgi.com; Wed, 28 Jun 2000 14:02:06 -0700 Date: Wed, 28 Jun 2000 14:02:06 -0700 From: blythe@bluevoid.com Message-Id: <200006282102.OAA13880@bluevoid.com> To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] SGI SI GLU integration Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing | > However, I had a couple of problems when trying to get it work: | > | > 1) The SGI glu.h file has some problem with Mesa gl.h file: | > | > a) The typedef void (*_GLfuncptr) defined in SGI gl.h but not in Mesa | > gl.h | > => idea: either add this typedef to Mesa gl.h, | > or use something different in SGI glu.h (like *_GLUfuncptr) | | My understanding was the _GLfuncptr was something added in order to | make work the autogeneration of the header files from the spec files. | It's supposed to be a private symbol. | | I like the idea of glu.h defining _GLUfuncptr if it needs it. The glu header generation drafts off of the GL header file generation and the _GLfuncptr leaked in. Looks like it would be straightforward to change to use _GLUfuncptr instead. | | | > b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are | > redefined in SGI glu.h (they are previously defined in Mesa gl.h) | > => idea: move them into SGI gl.h | | glu.h should not define any GL_* tokens. Could you send me your glu.h | file? yes, these are tokens are defined in the SI glu.h and gl.h and shouldn't be in the glu.h. This looks like an artifact of the way the files are generated and shouldn't be too hard to fix. I can fix both of these if no one objects. | > 2) The libGLU.so built from the GNUmakefile does not contain the C++ | > symbols like __pure_virtual. This is Ok if you link it with a C++ app, | > but it causes an undefined symbol when linking with C programs or | > libraries. I could work around this problem by linking by hand the | > libGLU.so using g++ instead of ld: | > | > g++ -shared -Wl,-soname,libGLU.so libutil/*.o libtess/*.o etc. | > | > Fixing this would require big change the GNUmakefile and included files | > in the ogl-sample package. I didn't do it because I was afraid of | > breaking other things (in the build of other libraries than GLU). | | When you build the libGLU.so shared library, could you add -lg++ | (the C++ runtime lib) to the list of objects? That way, libGLU.so | would be implicitly linked to libg++.so, so hopefully the end-user | could use the regular gcc linker. i think it is a little more troublesome than that (trust me :), but i think the fix i'm about to check in is the best compromise in terms of a clean Makefile and not having funny paths like /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66 embedded in the Makefile. david From owner-ogl-sample@oss.sgi.com Fri Jun 30 00:43:03 2000 Received: by oss.sgi.com id ; Fri, 30 Jun 2000 00:42:43 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:3777 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Fri, 30 Jun 2000 00:42:25 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id JAA09838; Fri, 30 Jun 2000 09:42:18 +0200 (MET DST) Message-ID: <395C5230.F85E7625@cyberbotics.com> Date: Fri, 30 Jun 2000 09:54:24 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.6-16apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com, mesa3d-dev@sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282033.NAA17628@bluevoid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Thanks to Brian, I checked out and build the lastest CVS version. It turns out that the GLU library is now properly built so that C++ symbols are now defined (i.e., I could like libGLU.so with simple C programs). However, except for the problems with the glu.h include file which are not yet fixed in the CVS, I discovered another problem that didn't exist in the tarball version: libGLU.so needs a couple of symbols that belongs to SGI libGL.so (I guess) and are not present in Mesa libGL.so. These symbols are: __glNURBSErrorString and __glTessErrorString They are used at the end of main/gfx/lib/glu/libutil/error.c and defined as external in gluint.h (in the same directory as error.c) I guess GLU should not assume that such symbols are defined in libGL.so and I think that the corresponding functions should be moved from SGI GL into SGI GLU -> __gluNURBSErrorString and __gluTessErrorString I had to comment out these two calls to get SGI libGLU.so link with Mesa libGL.so We are getting closer... -Olivier From owner-ogl-sample@oss.sgi.com Fri Jun 30 04:08:13 2000 Received: by oss.sgi.com id ; Fri, 30 Jun 2000 04:08:04 -0700 Received: from access-162.19.rev.fr.colt.net ([213.41.19.162]:53009 "EHLO mail.cyanide-studio.com") by oss.sgi.com with ESMTP id ; Fri, 30 Jun 2000 04:07:43 -0700 Received: from Seb (seb.cyanide-studio.com [10.1.8.6]) by mail.cyanide-studio.com (8.9.3/8.9.3) with SMTP id NAA20503 for ; Fri, 30 Jun 2000 13:07:40 +0200 Message-ID: <00c701bfe283$82e40d00$0608010a@Seb> From: "Sebastien Metrot" To: Subject: [ogl-sample] no anonymous ftp... Date: Fri, 30 Jun 2000 13:08:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hi! This is just to let you know that I can't access the opengl oss tarballs because the server refuses anonymous connections...How can I get it (except the CVS server..) Thanks in advance! Sebastien Metrot Check out NGL: http://ngl.sourceforge.net From owner-ogl-sample@oss.sgi.com Fri Jun 30 07:45:24 2000 Received: by oss.sgi.com id ; Fri, 30 Jun 2000 07:45:05 -0700 Received: from cmn2.cmn.net ([206.168.145.10]:45844 "EHLO cmn2.cmn.net") by oss.sgi.com with ESMTP id ; Fri, 30 Jun 2000 07:45:00 -0700 Received: from precisioninsight.com (jens2.cmn.net [207.174.125.34]) by cmn2.cmn.net (8.9.0/8.9.0) with ESMTP id IAA05632; Fri, 30 Jun 2000 08:44:27 -0600 Message-ID: <395CA4F7.19F095B@precisioninsight.com> Date: Fri, 30 Jun 2000 07:47:35 -0600 From: Brian Paul Organization: Precision Insight, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.3.51 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282033.NAA17628@bluevoid.com> <395C5230.F85E7625@cyberbotics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Olivier Michel wrote: > > Thanks to Brian, I checked out and build the lastest CVS version. > It turns out that the GLU library is now properly built so that C++ > symbols are now defined (i.e., I could like libGLU.so with simple C > programs). > > However, except for the problems with the glu.h include file which are > not yet fixed in the CVS, I discovered another problem that didn't exist > in the tarball version: > > libGLU.so needs a couple of symbols that belongs to SGI libGL.so (I > guess) and are not present in Mesa libGL.so. These symbols are: > > __glNURBSErrorString and __glTessErrorString > > They are used at the end of main/gfx/lib/glu/libutil/error.c and defined > as external in gluint.h (in the same directory as error.c) > > I guess GLU should not assume that such symbols are defined in libGL.so > and I think that the corresponding functions should be moved from SGI GL > into SGI GLU -> __gluNURBSErrorString and __gluTessErrorString > > I had to comment out these two calls to get SGI libGLU.so link with Mesa > libGL.so Have you determined exactly how/why these two functions are used? libGLU shouldn't use any internal libGL functions, in principle. But in practice, I'm not too surprised by this. In the worst case, I could add those funcs to Mesa (but I'd rather not). > We are getting closer... Yup. Thanks for doing this! -Brian From owner-ogl-sample@oss.sgi.com Fri Jun 30 08:27:54 2000 Received: by oss.sgi.com id ; Fri, 30 Jun 2000 08:27:35 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:12243 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Fri, 30 Jun 2000 08:27:09 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id RAA12636; Fri, 30 Jun 2000 17:27:02 +0200 (MET DST) Message-ID: <395CBF1D.DC20D9B9@cyberbotics.com> Date: Fri, 30 Jun 2000 17:39:09 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.6-16apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282033.NAA17628@bluevoid.com> <395C5230.F85E7625@cyberbotics.com> <395CA4F7.19F095B@precisioninsight.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Brian Paul wrote: > > Olivier Michel wrote: > > > > Thanks to Brian, I checked out and build the lastest CVS version. > > It turns out that the GLU library is now properly built so that C++ > > symbols are now defined (i.e., I could like libGLU.so with simple C > > programs). > > > > However, except for the problems with the glu.h include file which are > > not yet fixed in the CVS, I discovered another problem that didn't exist > > in the tarball version: > > > > libGLU.so needs a couple of symbols that belongs to SGI libGL.so (I > > guess) and are not present in Mesa libGL.so. These symbols are: > > > > __glNURBSErrorString and __glTessErrorString > > > > They are used at the end of main/gfx/lib/glu/libutil/error.c and defined > > as external in gluint.h (in the same directory as error.c) > > > > I guess GLU should not assume that such symbols are defined in libGL.so > > and I think that the corresponding functions should be moved from SGI GL > > into SGI GLU -> __gluNURBSErrorString and __gluTessErrorString > > > > I had to comment out these two calls to get SGI libGLU.so link with Mesa > > libGL.so > > Have you determined exactly how/why these two functions are used? > > libGLU shouldn't use any internal libGL functions, in principle. > But in practice, I'm not too surprised by this. In the worst case, > I could add those funcs to Mesa (but I'd rather not). Ok, I found the problem: Despite their strange names, I was wrong saying that these symbols were belonging to core GL. I finally found them in glu/libutil/glue.c. They were not found at run time because the GLU library is build without the -fpic option. I recompiled the glue.c and error.c files by hand simply adding the -fpic option to gcc and it worked fine. Symbols are not anymore missing at runtime. However, since I have no write access to ogl-sample CVS, I cannot commit anything to fix this. I guess this is pretty simple to fix (just add -fpic for Linux compilation in the main/root/usr/include/make/commondefs which is included by all GNUmakefile). Anyone with write access to CVS could fix this ? Thanks, -Olivier From owner-ogl-sample@oss.sgi.com Fri Jun 30 08:58:54 2000 Received: by oss.sgi.com id ; Fri, 30 Jun 2000 08:58:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37730 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 30 Jun 2000 08:58:05 -0700 Received: from arioch.engr.sgi.com (arioch.engr.sgi.com [130.62.54.161]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA05141 for ; Fri, 30 Jun 2000 09:03:34 -0700 (PDT) mail_from (shreiner@arioch.engr.sgi.com) Received: (from shreiner@localhost) by arioch.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA28468 for ogl-sample@oss.sgi.com; Fri, 30 Jun 2000 08:56:36 -0700 (PDT) Date: Fri, 30 Jun 2000 08:56:36 -0700 (PDT) From: Dave Shreiner Message-Id: <200006301556.IAA28468@arioch.engr.sgi.com> To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] no anonymous ftp... Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hi Sebastien, Thanks for the message. I had alerted the keepers of oss.sgi.com yesterday, but didn't get to send a note out to the email list. We're working on the problem. Thanx, Dave --------------------------------------------------------------------- Dave Shreiner Silicon Graphics, Inc. (650) 933-4899