openvrml-0.17.12: new port

[raphael@…]

OpenVRML is a cross-platform VRML and X3D browser and C++ runtime library.

[dbevans (David B. Evans)]

I tried building openvrml from your portfile but it failed with the following error:

/bin/sh ../libtool --tag=CXX   --mode=compile /usr/bin/g++-4.0 -DHAVE_CONFIG_H -I. -I..  -I../src/libopenvrml -I../src/libopenvrml -I../src/libopenvrml-gl -I../src/libopenvrml-gl -I/opt/local/include -D_THREAD_SAFE  -O2 -MT libopenvrml-gl/openvrml/gl/libopenvrml_gl_libopenvrml_gl_la-viewer.lo -MD -MP -MF libopenvrml-gl/openvrml/gl/.deps/libopenvrml_gl_libopenvrml_gl_la-viewer.Tpo -c -o libopenvrml-gl/openvrml/gl/libopenvrml_gl_libopenvrml_gl_la-viewer.lo `test -f 'libopenvrml-gl/openvrml/gl/viewer.cpp' || echo './'`libopenvrml-gl/openvrml/gl/viewer.cpp
mkdir libopenvrml-gl/openvrml/gl/.libs
 /usr/bin/g++-4.0 -DHAVE_CONFIG_H -I. -I.. -I../src/libopenvrml -I../src/libopenvrml -I../src/libopenvrml-gl -I../src/libopenvrml-gl -I/opt/local/include -D_THREAD_SAFE -O2 -MT libopenvrml-gl/openvrml/gl/libopenvrml_gl_libopenvrml_gl_la-viewer.lo -MD -MP -MF libopenvrml-gl/openvrml/gl/.deps/libopenvrml_gl_libopenvrml_gl_la-viewer.Tpo -c libopenvrml-gl/openvrml/gl/viewer.cpp  -fno-common -DPIC -o libopenvrml-gl/openvrml/gl/.libs/libopenvrml_gl_libopenvrml_gl_la-viewer.o
libopenvrml-gl/openvrml/gl/viewer.cpp: In function 'void<unnamed>::insertExtrusionCaps(GLUtesselator&, unsigned int, size_t, const std::vector<openvrml::vec3f, std::allocator<openvrml::vec3f> >&, const std::vector<openvrml::vec2f, std::allocator<openvrml::vec2f> >&)':
libopenvrml-gl/openvrml/gl/viewer.cpp:2054: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2054: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
libopenvrml-gl/openvrml/gl/viewer.cpp:2056: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2056: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
libopenvrml-gl/openvrml/gl/viewer.cpp:2058: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2058: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
libopenvrml-gl/openvrml/gl/viewer.cpp: In function 'void<unnamed>::insertShellTess(GLUtesselator&, const std::vector<<unnamed>::vertex_data, std::allocator<<unnamed>::vertex_data> >&, const std::vector<openvrml::int32, std::allocator<openvrml::int32> >&, bool, const std::vector<openvrml::color, std::allocator<openvrml::color> >&, const std::vector<openvrml::int32, std::allocator<openvrml::int32> >&, bool, const std::vector<openvrml::vec3f, std::allocator<openvrml::vec3f> >&, const std::vector<openvrml::int32, std::allocator<openvrml::int32> >&)':
libopenvrml-gl/openvrml/gl/viewer.cpp:2906: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2906: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
libopenvrml-gl/openvrml/gl/viewer.cpp:2909: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2909: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
libopenvrml-gl/openvrml/gl/viewer.cpp:2912: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2912: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
libopenvrml-gl/openvrml/gl/viewer.cpp:2915: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2915: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
libopenvrml-gl/openvrml/gl/viewer.cpp:2917: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)'
libopenvrml-gl/openvrml/gl/viewer.cpp:2917: error:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'
make[3]: *** [libopenvrml-gl/openvrml/gl/libopenvrml_gl_libopenvrml_gl_la-viewer.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Also you might want to add a mode line as the first line of the Portfile. See ​http://guide.macports.org/#development.creating-portfile.

[dbevans (David B. Evans)]

I forgot to say that I was building on Tiger (10.4.11 ppc) with XCode 2.5. Have not tested on 10.5.

[raphael@…]

Replying to devans@…:

I was building on Tiger (10.4.11 ppc) with XCode 2.5. Have not tested on 10.5.

Sorry, I only have 10.5.5 (Intel and PowerPC) here and it works for me.

What does

port -v -d configure openvrml

tell you about

checking for varargs GLU tesselator callback function type...

? On Tiger it should be yes and on Leopard no.

[dbevans (David B. Evans)]

Relevant result of

port -v -d configure openvrml

on Tiger is

checking for varargs GLU tesselator callback function type... no

[raphael@…]

Replying to devans@…:

checking for varargs GLU tesselator callback function type... no

Hm, I think this should be yes on Tiger. What does config.log say?

[dbevans (David B. Evans)]

Replying to raphael@…:

Replying to devans@…:

checking for varargs GLU tesselator callback function type... no

Hm, I think this should be yes on Tiger. What does config.log say?

From config.log:

configure:25531: checking for varargs GLU tesselator callback function type
configure:25565: /usr/bin/gcc-4.0 -c -D_THREAD_SAFE  -O2 -I/opt/local/include conftest.c >&5
conftest.c: In function 'main':
conftest.c:34: error: ISO C requires a named argument before '...'
configure:25571: $? = 1
configure: failed program was:
| /* confdefs.h.  */  
| #define PACKAGE_NAME "OpenVRML"
| #define PACKAGE_TARNAME "openvrml"
| #define PACKAGE_VERSION "0.17.9"
| #define PACKAGE_STRING "OpenVRML 0.17.9"
| #define PACKAGE_BUGREPORT "openvrml-develop@lists.sourceforge.net"
| #define PACKAGE "openvrml"
| #define VERSION "0.17.9"
| #define STDC_HEADERS 1 
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1 
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1 
| #define HAVE_PTHREAD 1
| #define X_DISPLAY_MISSING 1
| #define HAVE_OPENGL_GL_H 1
| #define HAVE_OPENGL_GLU_H 1
| /* end confdefs.h.  */
| 
| # ifdef HAVE_GL_GLU_H
| #   include <GL/glu.h>
| # else
| #   include <OpenGL/glu.h>
| # endif 
| int
| main () 
| {
| GLvoid (*func)(...); gluTessCallback(0, 0, func)
|   ;
|   return 0;
| }
configure:25587: result: no

[dbevans (David B. Evans)]

By the way, in addition to the problem above, I wonder if the default for the port shouldn't be to include X support as that's what most other ports do. Then have a +no_x11 variant to disable X support.

[braden@…]

Patch for ax_check_glu.m4

[braden@…]

Could someone running 10.4 check out ​http://autoconf-gl-macros.googlecode.com/svn/trunk and test the patch I've just attached here?

[braden@…]

Cc Me!

[raphael@…]

Replying to braden@…:

Could someone running 10.4 check out ​http://autoconf-gl-macros.googlecode.com/svn/trunk and test the patch I've just attached here?

I don't think that the patch works, because the compiler error

ISO C requires a named argument before '...'

means that there must be a named argument in the definition of func, not in the arguments of gluTessCallback. The patched configure check gives the same error on 10.5. If I try to compile something like

GLvoid (*func)(int, ...); gluTessCallback(0, 0, func);

I get the correct error

warning: passing argument 3 of ‘gluTessCallback’ from incompatible pointer type

I checked the definition of glueTessCallback in /System/Library/Frameworks/OpenGL.framework/Headers/glu.h, which is

void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)());

both on 10.5.5 and 10.4.11 (I had access to a 10.4 machine, but couldn't compile OpenVRML because of too little memory.).

So, our problem is not the header in the OpenGL framework. I think the problem is the X11 header in /usr/X11R6/include/GL/glu.h. On 10.5 it says:

typedef void (GLAPIENTRYP _GLUfuncptr)();

whereas on 10.4.11 it says:

/* Internal convenience typedefs */
#ifdef __cplusplus
typedef GLvoid (*_GLUfuncptr)();
#else
typedef GLvoid (*_GLUfuncptr)(GLvoid);
#endif

So, it seems that ... in the compiler error message really means GLvoid (not a variadic function) and that the problem is that configure uses the OpenGL framework headers, but later, during the compilation of OpenVRML, the X11 GLX headers are used.

[raphael@…]

Replying to raphael@…:

So, it seems that ... in the compiler error message really means GLvoid (not a variadic function) and that the problem is that configure uses the OpenGL framework headers, but later, during the compilation of OpenVRML, the X11 GLX headers are used.

I just did some compilation tests on 10.5.5. The default compiler of 10.5.5 (GCC 4.0.1 (Apple Inc. build 5484)) gives no error and no warning regardless of which definition of func, GLvoid (*func)(GLvoid) or GLvoid (*func)(), is used. It also does not matter if I use the OpenGL framework headers or the X11 headers (I tried both, those of 10.5.5 and those of 10.4.11.). This is not surprising as GLvoid is a typedef of void.

I guess that the compiler of 10.4.11 (Xcode 2.5) behaves differently.

[braden@…]

The function signature

void f();

means different things in C and C++. In C, it means "Here's a function f and I haven't defined its argument list yet." In C++, it means exactly the same thing as

void f(void);

While I'll grant it's possible that the error message is using the varargs notation to mean "the arg list is undefined", note that OpenVRML is entirely C++; and there is no concept of a declared function with an undefined arg list in C++.

On OS X 10.4, the GLU tessellation callback needs to be cast to a type that looks like this:

typedef void (*callback_t)(...);

While everywhere else (including 10.5), the type needs to be:

typedef void (*callback_t)(void);

I was never able to work out exactly why that is on 10.4. Like you, I scoured the headers and couldn't find any direct evidence of varargs being used in the tessellation callback signature. Nonetheless, the compiler on 10.4 clearly thinks that the callback type must look like void (*)(...). I do not think the X11 version of the headers is getting included.

[raphael@…]

Replying to braden@…:

The function signature

void f();

means different things in C and C++.

Thanks for your explanation! I wasn't aware of this important difference.

While I'll grant it's possible that the error message is using the varargs notation to mean "the arg list is undefined", note that OpenVRML is entirely C++; and there is no concept of a declared function with an undefined arg list in C++.

I propose that the configure script should use the C++ compiler instead of the C compiler to test for the callback function type, since ISO C obviously does not like GLvoid (*)(...). With the unpatched version of your configure script and using the C++ compiler, I finally get the correct error on 10.5.5:

error: invalid conversion from ‘GLvoid (*)(...)’ to ‘GLvoid (*)()’
error:   initializing argument 3 of ‘void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())’

[braden@…]

Yup, that's what needs to happen. I'll incorporate this into the autoconf test and push it into OpenVRML 0.17.11.

[dbevans (David B. Evans)]

I see that OpenVRML 0.17.11 has now been released. Do you have an updated Portfile to test?

[raphael@…]

Replying to devans@…:

I see that OpenVRML 0.17.11 has now been released. Do you have an updated Portfile to test?

Yes, I have one (see the attachment). But I didn't test all variants yet.

[dbevans (David B. Evans)]

Ok, I am building on Tiger ppc now.

My first impression is that if you want to have a pre-extract phase only for darwin 9, it might be easier and more readable to use a platform variant

platform darwin 9 {
    pre-extract {
        set minimum_xcodeversion 3.1
        .....
    }
}

[nerdling (Jeremy Lavergne)]

Portfile.2 builds on Leopard x86_64.

[dbevans (David B. Evans)]

Well, my report on Tiger (10.4.11) ppc isn't so good. I have the Apple supplied X11 installed but am using the xorg-* X11 libs from MacPorts.

There seems to be an X11 configure problem with the included gtkglext as follows:

=== configuring in lib/gtkglext (/opt/local/var/macports/build/_local_ports_graphics_openvrml/work/openvrml-0.17.11/lib/gtkglext)
configure: running /bin/sh ./configure --disable-option-checking '--prefix=/opt/local'  '--disable-script-node-javascript' '--disable-xembe
d' '--disable-player' '--disable-mozilla-plugin' '--with-x' 'CC=/usr/bin/gcc-4.0' 'CFLAGS=-O2' 'LDFLAGS=-L/opt/local/lib' 'CPPFLAGS=-I/opt/
local/include' 'CPP=/usr/bin/cpp-4.0' 'CXX=/usr/bin/g++-4.0' 'CXXFLAGS=-O2' 'FFLAGS=-O2' 'BOOST_LIB_SUFFIX=-mt' --cache-file=/dev/null --sr

but the result is

configuration:
        OpenGL CFLAGS:          -I/usr/X11R6/include -D_THREAD_SAFE 
        OpenGL LIBS:             -lGLU -lGL -L/usr/X11R6/lib -lX11  -lm
        multihead support:      yes
        debug:                  minimum
        extra defs:             

So it configuring to build against the Apple supplied X11 libs and GL instead of mesa and its dependencies.

I can't say much about the actual building as I can't get that to complete on this machine. When compiling this port, g++ takes up a huge amount of memory and so the compile slows to a crawl and gets through several files but then (after 12 hours or so of clock time) it finally crashes during compilation with a bus error:

/bin/sh ../libtool --tag=CXX   --mode=compile /usr/bin/g++-4.0 -DHAVE_CONFIG_H -I. -I..  -I../java -I../src/libopenvrml -I../src/libopenvrml -DOPENVRML_LIBDIR_=\"/opt/local/lib\" -DOPENVRML_PKGDATADIR_=\"/opt/local/share/openvrml\" -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -DBOOST_SPIRIT_THREADSAFE -DBOOST_SPIRIT_CLOSURE_LIMIT=6 -DPHOENIX_LIMIT=6 -I/opt/local/include -D_THREAD_SAFE  -I/opt/local/include   -I/opt/local/include/freetype2 -I/opt/local/include    -O2 -MT libopenvrml/openvrml/libopenvrml_libopenvrml_la-vrml97node.lo -MD -MP -MF libopenvrml/openvrml/.deps/libopenvrml_libopenvrml_la-vrml97node.Tpo -c -o libopenvrml/openvrml/libopenvrml_libopenvrml_la-vrml97node.lo `test -f 'libopenvrml/openvrml/vrml97node.cpp' || echo './'`libopenvrml/openvrml/vrml97node.cpp
 /usr/bin/g++-4.0 -DHAVE_CONFIG_H -I. -I.. -I../java -I../src/libopenvrml -I../src/libopenvrml -DOPENVRML_LIBDIR_=\"/opt/local/lib\" -DOPENVRML_PKGDATADIR_=\"/opt/local/share/openvrml\" -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -DBOOST_SPIRIT_THREADSAFE -DBOOST_SPIRIT_CLOSURE_LIMIT=6 -DPHOENIX_LIMIT=6 -I/opt/local/include -D_THREAD_SAFE -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -O2 -MT libopenvrml/openvrml/libopenvrml_libopenvrml_la-vrml97node.lo -MD -MP -MF libopenvrml/openvrml/.deps/libopenvrml_libopenvrml_la-vrml97node.Tpo -c libopenvrml/openvrml/vrml97node.cpp  -fno-common -DPIC -o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-vrml97node.o
In file included from /opt/local/include/jpeglib.h:28,
                 from libopenvrml/openvrml/vrml97node.cpp:32:
/opt/local/include/jconfig.h:12:1: warning: "HAVE_STDLIB_H" redefined
In file included from libopenvrml/openvrml/vrml97node.cpp:24:
../config.h:32:1: warning: this is the location of the previous definition
make[3]: *** [libopenvrml/openvrml/libopenvrml_libopenvrml_la-vrml97node.lo] Bus error
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I've done this 3 times with identical results.

Maybe not enough memory but I don't see this with other g++ compilations. Anyway, I'm not convinced this has anything to do with the port per se.

Concerning the X11 configuration problem, I'm not sure what the current recommended procedure is for handling this type of problem. Am copying jeremyhu for his input.

[raphael@…]

Replying to devans@…:

I can't say much about the actual building as I can't get that to complete on this machine. When compiling this port, g++ takes up a huge amount of memory and so the compile slows to a crawl and gets through several files but then (after 12 hours or so of clock time) it finally crashes during compilation with a bus error:

It is well known that OpenVRML currently needs a lot of memory to compile and some work work has been done to reduce that in future versions, see ​http://sourceforge.net/mailarchive/forum.php?thread_name=1222495081.13589.54.camel%40hinge.endoframe.net&forum_name=openvrml-develop. But I don't think that the bus error is caused by a memory problem. Can anybody else try to compile OpenVRML on Mac OS X 10.4.11?

Concerning the X11 configuration problem, I'm not sure what the current recommended procedure is for handling this type of problem.

I would propose to add the following to the Portfile (like in the xaos port):

platform macosx {
	if {[file exists ${prefix}/lib/pkgconfig/x11.pc]} {
		configure.args-append   --x-includes=${prefix}/include \
			--x-libraries=${prefix}/lib
	} else {
		configure.args-append   --x-includes=${x11prefix}/include \
			--x-libraries=${x11prefix}/lib
	}
}

Could you test if this works for you?

[raphael@…]

Replying to devans@…:

My first impression is that if you want to have a pre-extract phase only for darwin 9, it might be easier and more readable to use a platform variant

Well, I'm not sure if this would be better. Yes, it would be more readable, but it would also add another variant. If a port has a platform variant then the user might think that the port will be compiled and/or installed differently just for that platform. This is not the case here as this is just a simple test if the user has a current Xcode version. This test is also used in the graphviz ports, see ​http://trac.macports.org/changeset/47091.

[dbevans (David B. Evans)]

I would propose to add the following to the Portfile (like in the xaos port):

platform macosx {
	if {[file exists ${prefix}/lib/pkgconfig/x11.pc]} {
		configure.args-append   --x-includes=${prefix}/include \
			--x-libraries=${prefix}/lib
	} else {
		configure.args-append   --x-includes=${x11prefix}/include \
			--x-libraries=${x11prefix}/lib
	}
}

Could you test if this works for you?

Yes, I tested this on 10.4.11 ppc in both a default (xorg-*) X11 environment and also in one with global variant +system_x11 set.

In the first case

...
checking for X... libraries /opt/local/lib, headers /opt/local/include
...
configuration:
        OpenGL CFLAGS:          -I/opt/local/include -D_THREAD_SAFE 
        OpenGL LIBS:             -lGLU -lGL -L/opt/local/lib -lX11  -lm
        multihead support:      yes
        debug:                  minimum
        extra defs:

and in the second

...
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
...
configuration:
        OpenGL CFLAGS:          -I/usr/X11R6/include -D_THREAD_SAFE 
        OpenGL LIBS:             -lGLU -lGL -L/usr/X11R6/lib -lX11  -lm
        multihead support:      yes
        debug:                  minimum
        extra defs:

My only concern is that the X11 library path should come before the GL library specifications in both cases as that is where they are.

Build still fails with bus error as before but I'm hoping this is just my machine being over taxed.

[dbevans (David B. Evans)]

On the memory utilization issue when compiling parse_vrml97.cpp Braden says

On my machine, parse_vrml.cpp's high water mark in memory seems to be
somewhere between 900 MB and 1 GB. I think this means that OpenVRML
should compile comfortably in a non-parallel build on 64-bit machines
with at least 2 GB of memory; and on 32-bit machines with at least 1 GB
of memory. For machines with more memory, OpenVRML's build will
parallelize pretty nicely.

I concur with his memory usage figures. Virtual memory size gets up to almost 900 MB before hitting the bus error problem with significant thrashing of swap space. I'm using a G4 Power Mac (Quicksilver) with 640 MB of physical ram.

Have ordered another 1 GB of memory to bring it up to 1.5 GB.

However, I still think that there work to be done in breaking up these files to make things compile easier. Nothing else in MacPorts comes close to these memory usage figures.

[braden@…]

Replying to devans@…:

On the memory utilization issue when compiling parse_vrml97.cpp Braden says

On my machine, parse_vrml.cpp's high water mark in memory seems to be somewhere between 900 MB and 1 GB. I think this means that OpenVRML should compile comfortably in a non-parallel build on 64-bit machines with at least 2 GB of memory; and on 32-bit machines with at least 1 GB of memory. For machines with more memory, OpenVRML's build will parallelize pretty nicely.

These comments--taken from a posting to the openvrml-develop mailing list--apply to trunk OpenVRML; the situation with the 0.17.x series can be expected to be significantly worse. (Note that OpenVRML 0.17.x doesn't even have a file named parse_vrml.cpp.)

I concur with his memory usage figures. Virtual memory size gets up to almost 900 MB before hitting the bus error problem with significant thrashing of swap space. I'm using a G4 Power Mac (Quicksilver) with 640 MB of physical ram.

Is this from compiling trunk OpenVRML or 0.17.x?

Have ordered another 1 GB of memory to bring it up to 1.5 GB.

However, I still think that there work to be done in breaking up these files to make things compile easier. Nothing else in MacPorts comes close to these memory usage figures.

I wouldn't be the least bit surprised if nothing else in MacPorts includes Spirit grammars nearly as large as OpenVRML's.

[dbevans (David B. Evans)]

These comments--taken from a posting to the openvrml-develop mailing list--apply to trunk OpenVRML; the situation with the 0.17.x series can be expected to be significantly worse. (Note that OpenVRML 0.17.x doesn't even have a file named parse_vrml.cpp.)

Yes, I misquoted the file name. The file where I'm having trouble is vrml97node.cpp.

Is this from compiling trunk OpenVRML or 0.17.x?

0.17.11 using the Portfile under development in this ticket. If you like, I'll give it a try using your trunk code.

I wouldn't be the least bit surprised if nothing else in MacPorts includes Spirit grammars nearly as large as OpenVRML's.

I'm sure that's true. I'm just concerned that the amount of resources necessary to build this port successfully may put off some people who would otherwise adopt it. I know you've put a lot of work into this problem and I hope you'll continue to do so.

[braden@…]

Replying to devans@…:

These comments--taken from a posting to the openvrml-develop mailing list--apply to trunk OpenVRML; the situation with the 0.17.x series can be expected to be significantly worse. (Note that OpenVRML 0.17.x doesn't even have a file named parse_vrml.cpp.)

Yes, I misquoted the file name. The file where I'm having trouble is vrml97node.cpp.

Is this from compiling trunk OpenVRML or 0.17.x?

0.17.11 using the Portfile under development in this ticket. If you like, I'll give it a try using your trunk code.

Please do try the trunk. vrml97node.cpp has been completely broken up on the trunk and should no longer pose a problem.

I wouldn't be the least bit surprised if nothing else in MacPorts includes Spirit grammars nearly as large as OpenVRML's.

I'm sure that's true. I'm just concerned that the amount of resources necessary to build this port successfully may put off some people who would otherwise adopt it. I know you've put a lot of work into this problem and I hope you'll continue to do so.

The Spirit grammars get compiled in browser.cpp in 0.17.x; on the trunk that has been broken out into parse_vrml.cpp.

[dbevans (David B. Evans)]

Attached is a new Portfile that I made for a openvrml-devel port that builds from recent svn trunk. It compiled all of libopenvrml without problems (spliting up the files did indeed help tremendously) but failed when linking libopenvrml.8.dylib as follows

libtool: compile:  /usr/bin/g++-4.0 -DHAVE_CONFIG_H -I. -I.. -I../src/libopenvrml -I../src/libopenvrml -I./node -I./node/vrml97 -DOPENVRML_LIBDIR_=\"/opt/local/lib\" -DOPENVRML_PKGDATADIR_=\"/opt/local/share/openvrml\" -DOPENVRML_PKGLIBDIR_=\"/opt/local/lib/openvrml\" -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -D_THREAD_SAFE -I/opt/local/include/libxml2 -O2 -MT libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-node_metatype_registry_impl.lo -MD -MP -MF libopenvrml/openvrml/local/.deps/libopenvrml_libopenvrml_la-node_metatype_registry_impl.Tpo -c libopenvrml/openvrml/local/node_metatype_registry_impl.cpp -o libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-node_metatype_registry_impl.o >/dev/null 2>&1
mv -f libopenvrml/openvrml/local/.deps/libopenvrml_libopenvrml_la-node_metatype_registry_impl.Tpo libopenvrml/openvrml/local/.deps/libopenvrml_libopenvrml_la-node_metatype_registry_impl.Plo
/bin/sh ../libtool --tag=CXX   --mode=link /usr/bin/g++-4.0 -I/opt/local/include/freetype2 -I/opt/local/include   -D_THREAD_SAFE  -I/opt/local/include/libxml2   -O2 -version-info 8:8:0 -no-undefined -L/opt/local/lib -lxml2 -lpthread -lz -liconv -lm    -L/opt/local/lib -o libopenvrml/libopenvrml.la -rpath /opt/local/lib libopenvrml/openvrml/libopenvrml_libopenvrml_la-bad_url.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-vrml97_grammar.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_vrml_grammar.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-read_write_mutex.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-basetypes.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-field_value.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-event.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-exposedfield.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-scope.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-node.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-script.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-bounding_volume.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-scene.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-browser.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-viewer.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-rendering_context.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-frustum.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-node_impl_util.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-dl.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-uri.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-xml_reader.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-parse_vrml.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-component.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-proto.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-externproto.lo libopenvrml/openvrml/local/libopenvrml_libopenvrml_la-node_metatype_registry_impl.lo -lboost_thread-mt -lboost_filesystem-mt -lltdl 
libtool: link: /usr/bin/g++-4.0 -dynamiclib  -o libopenvrml/.libs/libopenvrml.8.dylib  libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-bad_url.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-vrml97_grammar.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_vrml_grammar.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-read_write_mutex.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-basetypes.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-field_value.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-event.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-exposedfield.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-scope.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-node.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-script.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-bounding_volume.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-scene.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-browser.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-viewer.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-rendering_context.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-frustum.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-node_impl_util.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-dl.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-uri.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-xml_reader.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-parse_vrml.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-component.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-proto.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-externproto.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-node_metatype_registry_impl.o   -L/opt/local/lib /opt/local/lib/libxml2.dylib -lpthread -lz /opt/local/lib/libiconv.dylib -lm -lboost_thread-mt -lboost_filesystem-mt /opt/local/lib/libltdl.dylib    -install_name  /opt/local/lib/libopenvrml.8.dylib -compatibility_version 9 -current_version 9.8 -Wl,-single_module
ld: Undefined symbols:
__ZN5boost6system19get_system_categoryEv
__ZN5boost6system20get_generic_categoryEv

This appears to be the same problem reported in #18894.

[dbevans (David B. Evans)]

Portfile that builds openvrml from svn trunk r33570.

[raphael@…]

This is the current portfile for OpenVRML 0.7.12. I've tested it on 10.5 with more than 1 GB of free memory.

[dbevans (David B. Evans)]

An overnight build of this latest portfile finished without error on 10.4.11 ppc with extra memory installed (1.5 GB total). Are there any additional issues outstanding or are you ready to commit the port?

[raphael@…]

Replying to devans@…:

Are there any additional issues outstanding or are you ready to commit the port?

For me, it's OK to commit the port. As I don't have commit rights, could you or somebody else do that?

[dbevans (David B. Evans)]

Committed in r48666. Thanks for the contribution and everyone's effort in getting the kinks ironed out.

[(none)]

Milestone Port Submissions deleted