Re: [openvrml-develop] Compiling 0.16.0+cvs on Mac OS X 10.4.8

[Braden M. <br...@en...>]

On Thu, 2006-10-05 at 10:42 +1300, Philip Lamb wrote:
> On 04/10/2006, at 1:37 PM, Braden McDaniel wrote:
> 
> > On Wed, 2006-10-04 at 12:24 +1300, Philip Lamb wrote:
> >> Firstly, I am building from the 0.16.0+cvs, under Mac OS X 10.4.8 on
> >> an Intel MacBook Pro.
> >
> > I hope this means you checked out using the OpenVRML-0_16_0-RELEASE or
> > the OpenVRML-0_16-BRANCH tag.
> >
> 
> No, I was trying to be too clever, and compiling from head. I have  
> reverted now to just the 0.16.0 release tarball, since it simplifies  
> these issues, and is what fink users would get anyway.
> 
> > BTW, configure should be looking for Rez in the spot that you are
> > specifying; thus it should not be necessary to set that environment
> > variable. If it *is* necessary, I'd like to know about it.
> 
> I have let you know this before, but here is the output the autoconf  
> "checking for Rez" step:
> 
> checking for Rez... /sw/bin:/sw/sbin:~/bin/i386-apple-darwin:/Users/ 
> phil/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/ 
> sbin:/usr/X11R6/bin:/Developer/Tools
> 
> i.e. it takes my whole path as the pathname of the rez executable.  
> This fails during the build, since its not a valid path for Rez ;-)

Argh. I goofed and was using the AC_PATH_PROG macro incorrectly. I've
attached a patch that I'll be committing shortly.

> This time, things went OK, except I did need to patch one file in  
> order to keep gcc 4.0.1 happy.
> 
> === PATCH BEGINS ===
> diff -urN openvrml-0.16.0/src/libopenvrml-gl/openvrml/gl/viewer.cpp  
> openvrml-0.16.0.patched/src/libopenvrml-gl/openvrml/gl/viewer.cpp
> --- openvrml-0.16.0/src/libopenvrml-gl/openvrml/gl/viewer.cpp    
> 2006-02-25 21:39:42.000000000 +1300
> +++ openvrml-0.16.0.patched/src/libopenvrml-gl/openvrml/gl/ 
> viewer.cpp   2006-10-05 09:47:27.000000000 +1300
> @@ -1965,7 +1965,7 @@
>        * As the type of callback functions given to OpenGL, this type  
> must have
>        * C linkage.
>        */
> -    typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)();
> +    typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)(...);
>       /**
>        * @internal
> @@ -2033,7 +2033,8 @@
>                               reinterpret_cast<TessCB> 
> (tessExtrusionBegin));
>               gluTessCallback(&tesselator, GLU_TESS_VERTEX_DATA,
>                               reinterpret_cast<TessCB> 
> (tessExtrusionVertex));
> -            gluTessCallback(&tesselator, GLU_TESS_END, glEnd);
> +            gluTessCallback(&tesselator, GLU_TESS_END,
> +                                       reinterpret_cast<GLvoid (*) 
> (...)>(glEnd));
>               if (mask & viewer::mask_bottom) {
>                   TessExtrusion bottom(&c[0][0],
> 
> === PATCH ENDS ===

Lovely. This is presumably a bug in the Apple/Fink OpenGL
implementation. The GLU 1.3 spec (the latest I know of) specifies the
signature of gluTessCallback to be
        
        void gluTessCallback(GLUtesselator *tessobj, GLenum which, void (*fn );())
        
I don't know what's up with that semicolon there (probably just a typo);
but clearly the third argument isn't a varargs function.

I guess I will need to write a configure test to spot this. I will do
that before releasing 0.16.1. Can I send you a patch to configure.ac to
test?

BTW, I'd expect this to give lots of other people problems, too.

> Finally, one difficulty we are running into on the Intel-based Macs  
> is that the last official mozilla version does not compile on Intel  
> Mac OS X. Our options for the mozilla-1.8 and later branches are  
> firefox and seamonkey. Since the key thing mozilla is needed for on  
> the Mac openvrml builds is script node javascript, I would like to  
> add this back in at some stage. However, fiddling with autoconfig and  
> patching header files is not my idea of fun, so perhaps its something  
> you'd like to consider - the linux builds will eventually run into  
> the same issue, with users preferring firefox and/or seamonkey over  
> an aging mozilla.

Regrettably, mozilla.[org|com] has bungled things badly here. They
always did a pretty weak job of packaging development headers for
Mozilla; and with the Firefox and Seamonkey they seem to have dropped
the ball completely, pushing the responsibility for fishing the correct
headers out of the source tree onto packagers. Supposedly there will be
some Mozilla Runtime Environment distribution at some point in the
future that will solve all these problems and life will be peachy.
        
Meanwhile, it sucks.
        
I note that it appears that a firefox-devel package has replaced the
mozilla-devel package for Fedora Core 6. I can only hope that the new
package actually provides things that are required for building browser
plug-ins.

> So I am quite close to finishing the updated fink packaging.. if only  
> cc1plus wasn't so ram hungry when compiling vrml97node.cpp.. :-) I'd  
> be finished sooner.

gcc is a pig; its management of large symbols (which happen when you use
templates nontrivially) appears to suck rather badly. If you can build
without debugging symbols, things go significantly faster. FWIW.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>