openvrml-develop

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

[Philip L. <ph...@ed...>]

Hi all,

I thought it about time I updated my Mac OS X fink openvrml package  
for the new release. However, I'm running into some fairly elementary  
issues attempting to build it.

Firstly, I am building from the 0.16.0+cvs, under Mac OS X 10.4.8 on  
an Intel MacBook Pro. I am using fink to satisfy the external  
dependencies. Here are my build steps so far:

fink install libpng3
fink install libjpeg
fink install pkgconfig
fink install boost-1.33
fink install sdl
fink install automake1.9
setenv CPPFLAGS "-I/sw/include"
setenv LDFLAGS "-L/sw/lib"
setenv REZ "/Developer/Tools/Rez"
./bootstrap

Here the build falls over for the first time.. the moving of the gtk  
plugin breaks the boostrap script and the underlying Makefile.am  
files are out of date. If I remove offending bits, I can configure:

./configure --with-apple-opengl-framework --disable-script-node- 
javascript --disable-gtkplug --disable-mozilla-plugin

which gets as far as looking for antlr:

checking for antlr... no
checking if antlr is available to the Java runtime... no
configure: error: antlr 2.7.4 not found
See `config.log' for more details.

I can't use antlr from fink, because its a newer version (2.8), and  
it appears that openvrml doesn't have any build commands to build the  
bundled antlr library. If I try to manually build the bundled antlr:

cd lib/antlr
make

it bombs out with:

Makefile:16: /openvrml/lib/antlr/../../scripts/Config.make: No such  
file or directory
Makefile:17: /openvrml/lib/antlr/../../scripts/Rules.make: No such  
file or directory
make: *** No rule to make target `/Users/phil/Documents/Development/ 
Projects/OpenVRML/openvrml-0.16.0-cvs/openvrml/lib/antlr/../../ 
scripts/Rules.make'.  Stop.

Can anyone illuminate?

Cheers,
Phil.

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

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

On Wed, 2006-10-04 at 12:24 +1300, Philip Lamb wrote:
> Hi all,
> 
> I thought it about time I updated my Mac OS X fink openvrml package  
> for the new release. However, I'm running into some fairly elementary  
> issues attempting to build it.
> 
> 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.

>  I am using fink to satisfy the external  
> dependencies. Here are my build steps so far:
> 
> fink install libpng3
> fink install libjpeg
> fink install pkgconfig
> fink install boost-1.33
> fink install sdl
> fink install automake1.9
> setenv CPPFLAGS "-I/sw/include"
> setenv LDFLAGS "-L/sw/lib"
> setenv REZ "/Developer/Tools/Rez"
> ./bootstrap
> 
> Here the build falls over for the first time.. the moving of the gtk  
> plugin breaks the boostrap script and the underlying Makefile.am  
> files are out of date.

I don't quite understand what this means.

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.

>  If I remove offending bits, I can configure:

By "remove the offending bits", are you referring to applying the patch
I provided in response to Thomas Engelmeier's recent posting? (If not,
you'll need it.  I'll push those changes to the OpenVRML-0_16-BRANCH
soon; but they aren't there as of this writing.)

> ./configure --with-apple-opengl-framework --disable-script-node- 
> javascript --disable-gtkplug --disable-mozilla-plugin
> 
> which gets as far as looking for antlr:
> 
> checking for antlr... no
> checking if antlr is available to the Java runtime... no
> configure: error: antlr 2.7.4 not found
> See `config.log' for more details.
> 
> I can't use antlr from fink, because its a newer version (2.8), and  
> it appears that openvrml doesn't have any build commands to build the  
> bundled antlr library.

The makefiles to build libantlr (as well as those to build the rest of
OpenVRML) are generated from the GNUmakefile.in files by config.status,
which gets run at the end of configure. You didn't get to the end of
configure, so that didn't happen.

The antlr executable has nothing to do with *building* libantlr;
configure checks to ensure that the version of the antlr executable on
the host system is compatible with the version of libantlr that is
included with the OpenVRML package.

You should not need a fink package of antlr in order to get this
working. The antlr executable is a Java program; so you should be able
to do something like:

        $ configure [OPTIONS] ANTLR='java -cp /path/to/antlr-2.7.4.jar antlr.Tool'

And BTW, Antlr 2.8 is not so much a newer version as it is a fork of the
codebase. Someone might want to make sure the fink packager for Antlr
knows that. The latest non-beta version of Antlr proper is 2.7.6. But
this really doesn't matter, since you must have 2.7.4 to build CVS
OpenVRML.

>  If I try to manually build the bundled antlr:
> 
> cd lib/antlr
> make

To be perfectly clear, lib/antlr is the antlr C++ support library needed
by antlr-generated parsers. It is *not* the source code for the antlr
executable.

> it bombs out with:
> 
> Makefile:16: /openvrml/lib/antlr/../../scripts/Config.make: No such  
> file or directory
> Makefile:17: /openvrml/lib/antlr/../../scripts/Rules.make: No such  
> file or directory
> make: *** No rule to make target `/Users/phil/Documents/Development/ 
> Projects/OpenVRML/openvrml-0.16.0-cvs/openvrml/lib/antlr/../../ 
> scripts/Rules.make'.  Stop.
> 
> Can anyone illuminate?

Per above, those aren't the makefiles you should be using; to get the
ones you need, configure will need to succeed.

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

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

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

On Tue, 2006-10-03 at 20:37 -0400, Braden McDaniel wrote:

> By "remove the offending bits", are you referring to applying the patch
> I provided in response to Thomas Engelmeier's recent posting? (If not,
> you'll need it.  I'll push those changes to the OpenVRML-0_16-BRANCH
> soon; but they aren't there as of this writing.)

I've checked in what I think is an equivalent (but slightly more
minimal) change to said branch. I'd appreciate it if you could test it
to confirm it works as intended. It will be rather painful for me to
create an environment where the GTK libraries are missing.

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

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

[Philip L. <ph...@ed...>]

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 ;-)

> The antlr executable has nothing to do with *building* libantlr;

OK, thanks.. this was not so clear, and is moot when building from  
the release package anyway.

> And BTW, Antlr 2.8 is not so much a newer version as it is a fork  
> of the
> codebase. Someone might want to make sure the fink packager for Antlr
> knows that.

Actually, I double checked, and the fink version is 2.7.5. My mistake.

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 ===

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.

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.

Cheers,
Phil.

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...>

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:

> 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.

In my previous posting I vented some frustration rather than ask you the
nature of the actual issue you're encountering. That's not clear to me
from your description here; so what is it? That is, what in OpenVRML's
build system is making it impossible (or unreasonably difficult) for you
to get things working with Firefox or Seamonkey?

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

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

[Philip L. <ph...@ed...>]

On 04/10/2006, at 3:34 PM, Braden McDaniel wrote:

> On Tue, 2006-10-03 at 20:37 -0400, Braden McDaniel wrote:
>
>> By "remove the offending bits", are you referring to applying the  
>> patch
>> I provided in response to Thomas Engelmeier's recent posting? (If  
>> not,
>> you'll need it.  I'll push those changes to the OpenVRML-0_16-BRANCH
>> soon; but they aren't there as of this writing.)
>
> I've checked in what I think is an equivalent (but slightly more
> minimal) change to said branch. I'd appreciate it if you could test it
> to confirm it works as intended. It will be rather painful for me to
> create an environment where the GTK libraries are missing.

Building on Mac OS X 10.4.8, from 0.16.0 release tarball, even when  
the --disable-gtkplug --disable-mozilla-plugin parameters are passed  
to configure, compilation still occurs of the gtkglext plugin!! The  
following directories are configured and compiled:
mozilla-plugin/lib/gtkglext/gdk/
mozilla-plugin/lib/gtkglext/x11/
mozilla-plugin/lib/gtkglext/gtk/
This obviously causes issues on a machine where glib and gtk are not  
installed!!

Here is a dump of a representative part of the buildlog:

=== SNIP ===
Making all in mozilla-plugin
Making all in lib
Making all in gtkglext
make  all-recursive
Making all in gdk
( cd . && glib-mkenums \
                 --fhead "#ifndef __GDK_GL_ENUM_TYPES_H__\n#define  
__GDK_GL_ENUM_TYPES_H__\n\n#include <glib-object.h>\n\nG_BEGIN_DECLS 
\n" \
                 --fprod "/* enumerations from \"@filename@\" */\n" \
                 --vhead "GType @enum_name@_get_type (void);\n#define  
GDK_TYPE_@ENUMSHORT@ (@enum_name@_get_type())\n" \
                 --ftail "G_END_DECLS\n\n#endif /*  
__GDK_GL_ENUM_TYPES_H__ */" \
         gdkgl.h gdkgldefs.h gdkglversion.h gdkgltokens.h  
gdkgltypes.h gdkglinit.h gdkglquery.h gdkglconfig.h gdkglcontext.h  
gdkgldrawable.h gdkglpixmap.h gdkglwindow.h gdkglfont.h gdkglshapes.h  
gdkglglext.h ) >> xgen-geth \
&& (cmp -s xgen-geth gdkglenumtypes.h || cp xgen-geth  
gdkglenumtypes.h ) \
&& rm -f xgen-geth \
&& echo timestamp > stamp-gdkglenumtypes-h
( cd . && glib-mkenums \
                 --fhead "#include \"gdkgl.h\"" \
                 --fprod "\n/* enumerations from \"@filename@\" */" \
                 --vhead "GType\n@enum_name@_get_type (void)\n{\n   
static GType etype = 0;\n  if (etype == 0) {\n    static const  
G@Type@Value values[] = {" \
                 --vprod "      { @VALUENAME@, \"@VALUENAME@\",  
\"@valuenick@\" }," \
                 --vtail "      { 0, NULL, NULL }\n    };\n    etype  
= g_@type@_register_static (\"@EnumName@\", values);\n  }\n  return  
etype;\n}\n" \
         gdkgl.h gdkgldefs.h gdkglversion.h gdkgltokens.h  
gdkgltypes.h gdkglinit.h gdkglquery.h gdkglconfig.h gdkglcontext.h  
gdkgldrawable.h gdkglpixmap.h gdkglwindow.h gdkglfont.h gdkglshapes.h  
gdkglglext.h ) > xgen-getc \
&& cp xgen-getc gdkglenumtypes.c  \
&& rm -f xgen-getc
make  all-recursive
Making all in glext
make[8]: Nothing to be done for `all'.
Making all in x11
if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H - 
I. -I. -I../.. -DG_LOG_DOMAIN=\"GdkGLExt\" -DGDK_GL_COMPILATION - 
DINSIDE_GDK_GL_X11 -I../.. -I../../gdk -I../../gdk -DG_ENABLE_DEBUG - 
I/usr/X11R6/include -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include  
-I/sw/include/pango-1.0 -I/usr/X11R6/include -I/usr/X11R6/include/ 
freetype2 -I/sw/include/gtk-2.0 -I/sw/lib/gtk-2.0/include    - 
DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED - 
DGDK_PIXBUF_DISABLE_DEPRECATED  -I/sw/include  -g -O2 -Wall -g -MT  
gdkglquery-x11.lo -MD -MP -MF ".deps/gdkglquery-x11.Tpo" -c -o  
gdkglquery-x11.lo gdkglquery-x11.c; \
=== SNIP ===

However the issue seems to be much earlier, with these directories  
still being included in the configure procedure.

Regards,
Phil.

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 14:44 +1300, Philip Lamb wrote:
> On 04/10/2006, at 3:34 PM, Braden McDaniel wrote:
> 
> > On Tue, 2006-10-03 at 20:37 -0400, Braden McDaniel wrote:
> >
> >> By "remove the offending bits", are you referring to applying the  
> >> patch
> >> I provided in response to Thomas Engelmeier's recent posting? (If  
> >> not,
> >> you'll need it.  I'll push those changes to the OpenVRML-0_16-BRANCH
> >> soon; but they aren't there as of this writing.)
> >
> > I've checked in what I think is an equivalent (but slightly more
> > minimal) change to said branch. I'd appreciate it if you could test it
> > to confirm it works as intended. It will be rather painful for me to
> > create an environment where the GTK libraries are missing.
> 
> Building on Mac OS X 10.4.8, from 0.16.0 release tarball, even when  
> the --disable-gtkplug --disable-mozilla-plugin parameters are passed  
> to configure, compilation still occurs of the gtkglext plugin!! The  
> following directories are configured and compiled:
> mozilla-plugin/lib/gtkglext/gdk/
> mozilla-plugin/lib/gtkglext/x11/
> mozilla-plugin/lib/gtkglext/gtk/
> This obviously causes issues on a machine where glib and gtk are not  
> installed!!

Er... Whoops. I could swear I made some attempt to prevent this; but
I'll be damned if I can find any evidence of it.

The attached patch should help; however, you'll need to get the
OpenVRML-0_16-BRANCH from CVS in order to apply it.

In theory it should be possible to backport this patch to 0.16.0. The
change to configure.ac should instead be made to
mozilla-plugin/configure.ac; and the change to lib/Makefile.am should
instead be made to mozilla-plugin/lib/Makefile.am.

> However the issue seems to be much earlier, with these directories  
> still being included in the configure procedure.

That much will happen regardless. We just need to keep make from
recursing into them.

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