[MacPorts] #16981: openvrml-0.17.9: new port
MacPorts
noreply at macports.org
Fri Mar 6 16:29:26 PST 2009
#16981: openvrml-0.17.9: new port
--------------------------------+-------------------------------------------
Reporter: raphael@… | Owner: macports-tickets@…
Type: enhancement | Status: new
Priority: Normal | Milestone: Port Submissions
Component: ports | Version: 1.6.0
Keywords: vrml new port | Port: openvrml
--------------------------------+-------------------------------------------
Changes (by devans@…):
* cc: jeremyhu@… (added)
Comment:
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.
--
Ticket URL: <http://trac.macports.org/ticket/16981#comment:20>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list