freeglut

Hi all,

I just joined the project.

Firstly, I'd like to add at least one new function which Mark Kilgard 
doesn't want in the original GLUT:  glutGetProcAddress().  It's 
basically just a wrapper for glXGetProcAddressARB / 
wglGetProcAddress(), but it can also return pointers to glut*() 
functions too.

Secondly, I'm wondering if there's any plans for a new official release?

-Brian

Re: [Freeglut-developer] contributions and status From: Steve Baker <sjbaker1@ai...> - 2003-06-17 21:47 Brian Paul wrote: > Firstly, I'd like to add at least one new function which Mark Kilgard > doesn't want in the original GLUT: glutGetProcAddress(). It's > basically just a wrapper for glXGetProcAddressARB / wglGetProcAddress(), > but it can also return pointers to glut*() functions too. That's a reasonable addition. Having it return pointers to GLUT functions is an interesting idea - but it has limited value so long as GLUT-classic doesn't implement it. If there were LOTS of GLUT clones out there and they all implemented it, it would be immensely valuable. Still, it's not hard to implement I guess. > Secondly, I'm wondering if there's any plans for a new official release? I've been rather out of freeglut development for a long while now - John Fay is the *actual* maintainer-in-chief, I only hold the honorary title (which I'd gladly give up)! John has been doing quite a bit of work on the library and I think it has to be his call as to when he's reached a 'natural break' when a new release could be made. I think we are long overdue for one - if only to stop the all-to-frequent "Has this project died?" emails! ---------------------------- Steve Baker ------------------------- HomeEmail: <sjbaker1@...> WorkEmail: <sjbaker@...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK-----

Re: [Freeglut-developer] contributions and status From: Brian Paul <brian@tu...> - 2003-06-17 22:18 Steve Baker wrote: > Brian Paul wrote: > >> Firstly, I'd like to add at least one new function which Mark Kilgard >> doesn't want in the original GLUT: glutGetProcAddress(). It's >> basically just a wrapper for glXGetProcAddressARB / >> wglGetProcAddress(), but it can also return pointers to glut*() >> functions too. > > > That's a reasonable addition. Having it return pointers to GLUT functions > is an interesting idea - but it has limited value so long as GLUT-classic > doesn't implement it. If there were LOTS of GLUT clones out there and they > all implemented it, it would be immensely valuable. Returning pointers to glut*() functions is a forward-looking feature. > Still, it's not hard to implement I guess. > >> Secondly, I'm wondering if there's any plans for a new official release? > > > I've been rather out of freeglut development for a long while now - John > Fay is the *actual* maintainer-in-chief, I only hold the honorary title > (which I'd gladly give up)! > > John has been doing quite a bit of work on the library and I think it > has to be his call as to when he's reached a 'natural break' when a new > release could be made. > > I think we are long overdue for one - if only to stop the all-to-frequent > "Has this project died?" emails! Right. I think the Linux disto vendors are anxious for this too. -Brian

Re: [Freeglut-developer] contributions and status From: Eric Sandall <eric@sa...> - 2003-06-17 23:09 Brian Paul said: > Right. I think the Linux disto vendors are anxious for this too. > > -Brian RedHat especially has been talking about removing glut entirely from their distro due to the licensing and some of the problems that not being able to change it may cause. They have also talked about using freeglut as a replacement, but the lack of visible releases has them thinking it is dead. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90734 (No access anymore, RH seems to have removed read permissions...) -sandalle -- PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61 http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61 Eric Sandall | Source Mage GNU/Linux Developer eric@... | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/

Re: [Freeglut-developer] contributions and status From: Mike A. Harris <mharris@ww...> - 2003-06-18 15:15 On Tue, 17 Jun 2003, Eric Sandall wrote: >Brian Paul said: >> Right. I think the Linux disto vendors are anxious for this too. >> >> -Brian > >RedHat especially has been talking about removing glut entirely from their >distro due to the licensing and some of the problems that not being able >to change it may cause. They have also talked about using freeglut as a >replacement, but the lack of visible releases has them thinking it is >dead. I can comment officially on this for Red Hat. I've already added freeglut to rawhide about 2-3 weeks or so ago, in hopes people would start playing with it and any problems could be found sooner than later, however I haven't yet removed GLUT from rawhide so that may be counter to my goal. ;o) My plan is to have freeglut completely replace GLUT in Red Hat Linux, as freeglut is truely free software with an acceptable license, and that is important to both myself as an OSS developer, and to Red Hat as a company. >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90734 (No access >anymore, RH seems to have removed read permissions...) Yeah, the bug started turning into a complaint center for people who require GLUT to bitch and whine about my plan of removing GLUT and replacing it with freeglut, so I killed the bug report as it no longer served any useful purpose. Basically, unless major problems arise, which I majorly doubt, freeglut is now officially part of Red Hat Linux, and GLUT will most likely be removed in the next release. I may remove GLUT now anyway, as it can be added back later if problems arise with freeglut that aren't fixable in time for our next release. This would further push people to use freeglut instead as well. Any comments/feedback on my plans, etc. would be greatly appreciated. TIA -- Mike A. Harris

Re: [Freeglut-developer] contributions and status From: Brian Paul <brian@tu...> - 2003-06-18 16:27 Mike A. Harris wrote: > On Tue, 17 Jun 2003, Eric Sandall wrote: > > >>Brian Paul said: >> >>>Right. I think the Linux disto vendors are anxious for this too. >>> >>>-Brian >> >>RedHat especially has been talking about removing glut entirely from their >>distro due to the licensing and some of the problems that not being able >>to change it may cause. They have also talked about using freeglut as a >>replacement, but the lack of visible releases has them thinking it is >>dead. > > > I can comment officially on this for Red Hat. I've already added > freeglut to rawhide about 2-3 weeks or so ago, in hopes people > would start playing with it and any problems could be found > sooner than later, however I haven't yet removed GLUT from > rawhide so that may be counter to my goal. ;o) > > My plan is to have freeglut completely replace GLUT in Red Hat > Linux, as freeglut is truely free software with an acceptable > license, and that is important to both myself as an OSS > developer, and to Red Hat as a company. > > > >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90734 (No access >>anymore, RH seems to have removed read permissions...) > > > Yeah, the bug started turning into a complaint center for people > who require GLUT to bitch and whine about my plan of removing > GLUT and replacing it with freeglut, so I killed the bug report > as it no longer served any useful purpose. > > Basically, unless major problems arise, which I majorly doubt, > freeglut is now officially part of Red Hat Linux, and GLUT will > most likely be removed in the next release. I may remove GLUT > now anyway, as it can be added back later if problems arise with > freeglut that aren't fixable in time for our next release. This > would further push people to use freeglut instead as well. > > Any comments/feedback on my plans, etc. would be greatly > appreciated. Have you considered installing symlinks pointing from libglut.so.3 to libfreeglut-1.3.so? I think that could help users. I'd like to see GLUT programs link/run with the original GLUT or FreeGLUT without recompiling/relinking. Also note that FreeGLUT produces the following libs: libfreeglut-1.3.a libfreeglut-1.3.la -> ../libfreeglut-1.3.la libfreeglut-1.3.lai libfreeglut-1.3.so -> libfreeglut-1.3.so.0.0.0* libfreeglut-1.3.so.0 -> libfreeglut-1.3.so.0.0.0* libfreeglut-1.3.so.0.0.0* I'm wondering why the typical conventions aren't used to wind up with: libfreeglut.so -> libfreeglut.so.1 libfreeglut.so.1 -> libfreeglut.so.1.3 libfreeglut.so.1.3 -Brian

Re: [Freeglut-developer] contributions and status From: Mike A. Harris <mharris@ww...> - 2003-06-19 00:04 On Wed, 18 Jun 2003, Brian Paul wrote: >> Yeah, the bug started turning into a complaint center for people >> who require GLUT to bitch and whine about my plan of removing >> GLUT and replacing it with freeglut, so I killed the bug report >> as it no longer served any useful purpose. >> >> Basically, unless major problems arise, which I majorly doubt, >> freeglut is now officially part of Red Hat Linux, and GLUT will >> most likely be removed in the next release. I may remove GLUT >> now anyway, as it can be added back later if problems arise with >> freeglut that aren't fixable in time for our next release. This >> would further push people to use freeglut instead as well. >> >> Any comments/feedback on my plans, etc. would be greatly >> appreciated. > >Have you considered installing symlinks pointing from libglut.so.3 to >libfreeglut-1.3.so? I think that could help users. > >I'd like to see GLUT programs link/run with the original GLUT or >FreeGLUT without recompiling/relinking. Absolutely, and I was just about to ask others about wether they thought this was a good idea or not. If I make the change, it will help to actually push GLUT out now too. ;o) >Also note that FreeGLUT produces the following libs: > >libfreeglut-1.3.a >libfreeglut-1.3.la -> ../libfreeglut-1.3.la >libfreeglut-1.3.lai >libfreeglut-1.3.so -> libfreeglut-1.3.so.0.0.0* >libfreeglut-1.3.so.0 -> libfreeglut-1.3.so.0.0.0* >libfreeglut-1.3.so.0.0.0* > >I'm wondering why the typical conventions aren't used to wind up with: > >libfreeglut.so -> libfreeglut.so.1 >libfreeglut.so.1 -> libfreeglut.so.1.3 >libfreeglut.so.1.3 I was also wondering that. ;o) Uli Drepper wrote a fantastic whitepaper on DSOs which I learned a tonne from that I wasn't aware of when I read it. Everyone whom I've passed the URL onto has come back and told me they've also learned a tonne about DSOs after reading it. If anyone is interested, here is the link to Uli's whitepaper: http://people.redhat.com/drepper/dsohowto.pdf If you find it useful, please let me know and I'll pass on your feedback to Uli, or you can mail him directly at drepper@... It's quite a good read. Hope this helps. Take care, TTYL -- Mike A. Harris

Re: [Freeglut-developer] contributions and status From: Eric Sandall <eric@sa...> - 2003-06-24 01:28 Brian Paul said: > Have you considered installing symlinks pointing from libglut.so.3 to > libfreeglut-1.3.so? I think that could help users. > > I'd like to see GLUT programs link/run with the original GLUT or > FreeGLUT without recompiling/relinking. > > Also note that FreeGLUT produces the following libs: > > libfreeglut-1.3.a > libfreeglut-1.3.la -> ../libfreeglut-1.3.la > libfreeglut-1.3.lai > libfreeglut-1.3.so -> libfreeglut-1.3.so.0.0.0* > libfreeglut-1.3.so.0 -> libfreeglut-1.3.so.0.0.0* > libfreeglut-1.3.so.0.0.0* > > I'm wondering why the typical conventions aren't used to wind up with: > > libfreeglut.so -> libfreeglut.so.1 > libfreeglut.so.1 -> libfreeglut.so.1.3 > libfreeglut.so.1.3 > > -Brian I can't find where the symlinks are decided to be created, I've done the following: $ grep libfreeglut * -R from the freeglut/ directory, and it reported this: freeglut-1.3/Makefile.am:lib_LTLIBRARIES = libfreeglut-1.3.la freeglut-1.3/Makefile.am:libfreeglut_1_3_la_SOURCES = freeglut_callbacks.c \ freeglut-1.3/Makefile.am:libfreeglut_1_3_la_LIBADD = $(LIBM) $(X_LIBS) -lGL -lGLU -lXext -lX11 -lXxf86vm freeglut-1.3/Makefile.am:libfreeglut_1_3_la_LDFLAGS = -version-info 0:0:0 src/Makefile.am:lib_LTLIBRARIES = libfreeglut-1.3.la src/Makefile.am:libfreeglut_1_3_la_SOURCES = freeglut_callbacks.c \ src/Makefile.am:libfreeglut_1_3_la_LIBADD = $(LIBM) $(X_LIBS) -lGL -lGLU -lXext -lX11 -lXxf86vm src/Makefile.am:libfreeglut_1_3_la_LDFLAGS = -version-info 0:0:0 tests/Makefile.am:one_LDFLAGS = -export-dynamic -dlpreopen ../src/libfreeglut-1.3.la I believe the information is hidden in 'aclocal.m4' (it has references to .so and lib$name and looks like it plays with libraries), but that's for Linux (IIRC), and I'm not much of an autoconf/automake person. I'll keep playing around, but if anyone has any insite, it's welcome. :) Below is the text from: $ grep "\.so" aclocal.m4 aclocal.m4:# PORTME Fill in your ld.so characteristics aclocal.m4:shrext=".so" aclocal.m4:dynamic_linker="$host_os ld.so" aclocal.m4: # If using run time linking (on AIX 4.2 or later) use lib<name>.so aclocal.m4: dynamic_linker="$host_os ld.so" aclocal.m4: # the default ld.so.conf also contains /usr/contrib/lib and aclocal.m4: shrext='$(test .$module = .yes && echo .so || echo .dylib)' aclocal.m4: shrext='.so' aclocal.m4: dynamic_linker="$host_os dld.so" aclocal.m4: # We used to test for /lib/ld.so.1 and disable shared libraries on aclocal.m4: dynamic_linker='GNU/Linux ld.so' aclocal.m4: dynamic_linker='NetBSD (a.out) ld.so' aclocal.m4: lt_cv_file_magic_test_file=/shlib/libc.so aclocal.m4: lt_cv_file_magic_test_file=`echo /usr/lib/libc.so.*` aclocal.m4: lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so aclocal.m4: lt_cv_file_magic_test_file=`echo /lib${libsuff}/libc.so*` aclocal.m4: lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so` aclocal.m4: lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|_pic\.a)$' aclocal.m4: lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|_pic\.a)$' aclocal.m4: lt_cv_file_magic_test_file=/usr/lib/libnls.so aclocal.m4: lt_cv_file_magic_test_file=`echo /usr/lib/libc.so.*` aclocal.m4: lt_cv_file_magic_test_file=/shlib/libc.so aclocal.m4: lt_cv_file_magic_test_file=/lib/libc.so aclocal.m4: lt_cv_file_magic_test_file=`echo /usr/lib/libc.so*` aclocal.m4: lt_cv_file_magic_test_file=/lib/libc.so aclocal.m4: # ends with ".so" (or ".sl" for HP-UX), so rename the library aclocal.m4: _LT_AC_TAGVAR(archive_cmds, $1)='tempext=`echo $shared_ext | $SED -e '\''s/\([[^()0-9A-Za-z{}]]\)/\\\\\1/g'\''`; templib=`echo $lib | $SED -e "s/\${tempext}\..*/.so/"`; $CC $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags --soname $soname -o \$templib; mv \$templib $lib' aclocal.m4: _LT_AC_TAGVAR(archive_expsym_cmds, $1)='tempext=`echo $shared_ext | $SED -e '\''s/\([[^()0-9A-Za-z{}]]\)/\\\\\1/g'\''`; templib=`echo $lib | $SED -e "s/\${tempext}\..*/.so/"`; $CC $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags --soname $soname -o \$templib ${wl}-retain-symbols-file,$export_symbols; mv \$templib $lib' aclocal.m4: # ends with ".so" (or ".sl" for HP-UX), so rename the library aclocal.m4: _LT_AC_TAGVAR(archive_cmds, $1)='tempext=`echo $shared_ext | $SED -e '\''s/\([[^()0-9A-Za-z{}]]\)/\\\\\1/g'\''`; templib=`echo $lib | $SED -e "s/\${tempext}\..*/.so/"`; $CC $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags --soname $soname -o \$templib; mv \$templib $lib' aclocal.m4: # ends with ".so" (or ".sl" for HP-UX), so rename the library aclocal.m4: _LT_AC_TAGVAR(archive_cmds, $1)='tempext=`echo $shared_ext | $SED -e '\''s/\([[^()0-9A-Za-z{}]]\)/\\\\\1/g'\''`; templib=`echo $lib | $SED -e "s/\${tempext}\..*/.so/"`; $CC $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags --soname $soname -o \$templib; mv \$templib $lib' aclocal.m4:# Shared library suffix (normally ".so"). aclocal.m4: # Tell ltmain to make .dll files, not .so files. -sandalle -- PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61 http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61 Eric Sandall | Source Mage GNU/Linux Developer eric@... | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/

Re: [Freeglut-developer] contributions and status From: Brian Paul <brian@tu...> - 2003-06-24 14:15 Eric Sandall wrote: > Brian Paul said: > >>Have you considered installing symlinks pointing from libglut.so.3 to >>libfreeglut-1.3.so? I think that could help users. >> >>I'd like to see GLUT programs link/run with the original GLUT or >>FreeGLUT without recompiling/relinking. >> >>Also note that FreeGLUT produces the following libs: >> >>libfreeglut-1.3.a >>libfreeglut-1.3.la -> ../libfreeglut-1.3.la >>libfreeglut-1.3.lai >>libfreeglut-1.3.so -> libfreeglut-1.3.so.0.0.0* >>libfreeglut-1.3.so.0 -> libfreeglut-1.3.so.0.0.0* >>libfreeglut-1.3.so.0.0.0* >> >>I'm wondering why the typical conventions aren't used to wind up with: >> >>libfreeglut.so -> libfreeglut.so.1 >>libfreeglut.so.1 -> libfreeglut.so.1.3 >>libfreeglut.so.1.3 >> >>-Brian > > > I can't find where the symlinks are decided to be created, I've done the > following: > > $ grep libfreeglut * -R > > from the freeglut/ directory, and it reported this: > > freeglut-1.3/Makefile.am:lib_LTLIBRARIES = libfreeglut-1.3.la > freeglut-1.3/Makefile.am:libfreeglut_1_3_la_SOURCES = freeglut_callbacks.c \ > freeglut-1.3/Makefile.am:libfreeglut_1_3_la_LIBADD = $(LIBM) $(X_LIBS) > -lGL -lGLU -lXext -lX11 -lXxf86vm > freeglut-1.3/Makefile.am:libfreeglut_1_3_la_LDFLAGS = -version-info 0:0:0 > src/Makefile.am:lib_LTLIBRARIES = libfreeglut-1.3.la > src/Makefile.am:libfreeglut_1_3_la_SOURCES = freeglut_callbacks.c \ > src/Makefile.am:libfreeglut_1_3_la_LIBADD = $(LIBM) $(X_LIBS) -lGL -lGLU > -lXext -lX11 -lXxf86vm > src/Makefile.am:libfreeglut_1_3_la_LDFLAGS = -version-info 0:0:0 > tests/Makefile.am:one_LDFLAGS = -export-dynamic -dlpreopen > ../src/libfreeglut-1.3.la > > I believe the information is hidden in 'aclocal.m4' (it has references to > .so and lib$name and looks like it plays with libraries), but that's for > Linux (IIRC), and I'm not much of an autoconf/automake person. I'll keep > playing around, but if anyone has any insite, it's welcome. :) I have a feeling that making the symlinks with autoconf/automake will be like pulling teeth. Who contributed the automake stuff in the first place? -Brian

4 messages have been excluded from this view by a project administrator.