Menu
▾
▴
openvrml-develop
|
From: Philip L. <ph...@ed...> - 2006-11-23 19:20:26
|
Hi all, I finally got around to building OpenVRML on Mac OS X on a PowerPC machine, and have encountered a build failure during linking. This doesn't appear on Mac OS X x86 and I'm at a bit of a loss to diagnose the cause: Making all in libopenvrml make all-am depbase=`echo openvrml/basetypes.lo | sed 's|[^/]*$|.deps/&|;s|\.lo $||'`; \ if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java -I../../src/ libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" -DOPENVRML_PKGDATADIR_=\"/ sw/share/openvrml\" -DBOOST_SPIRIT_THREADSAFE - DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 -MT openvrml/basetypes.lo -MD -MP -MF "$depbase.Tpo" -c -o openvrml/ basetypes.lo openvrml/basetypes.cpp; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi mkdir openvrml/.libs g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/basetypes.lo -MD -MP -MF openvrml/.deps/basetypes.Tpo -c openvrml/basetypes.cpp -fno-common -DPIC -o openvrml/.libs/basetypes.o g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/basetypes.lo -MD -MP -MF openvrml/.deps/basetypes.Tpo -c openvrml/basetypes.cpp -o openvrml/basetypes.o >/dev/null 2>&1 depbase=`echo openvrml/field_value.lo | sed 's|[^/]*$|.deps/&|;s|\.lo $||'`; \ if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java -I../../src/ libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" -DOPENVRML_PKGDATADIR_=\"/ sw/share/openvrml\" -DBOOST_SPIRIT_THREADSAFE - DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 -MT openvrml/field_value.lo -MD -MP -MF "$depbase.Tpo" -c -o openvrml/ field_value.lo openvrml/field_value.cpp; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/field_value.lo -MD -MP -MF openvrml/.deps/field_value.Tpo -c openvrml/field_value.cpp -fno-common -DPIC -o openvrml/.libs/ field_value.o g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/field_value.lo -MD -MP -MF openvrml/.deps/field_value.Tpo -c openvrml/field_value.cpp -o openvrml/field_value.o >/dev/null 2>&1 depbase=`echo openvrml/event.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \ if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java -I../../src/ libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" -DOPENVRML_PKGDATADIR_=\"/ sw/share/openvrml\" -DBOOST_SPIRIT_THREADSAFE - DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 -MT openvrml/event.lo -MD -MP -MF "$depbase.Tpo" -c -o openvrml/ event.lo openvrml/event.cpp; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/event.lo -MD -MP -MF openvrml/.deps/event.Tpo -c openvrml/ event.cpp -fno-common -DPIC -o openvrml/.libs/event.o g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/event.lo -MD -MP -MF openvrml/.deps/event.Tpo -c openvrml/ event.cpp -o openvrml/event.o >/dev/null 2>&1 depbase=`echo openvrml/exposedfield.lo | sed 's|[^/]*$|.deps/&|;s|\.lo $||'`; \ if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java -I../../src/ libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" -DOPENVRML_PKGDATADIR_=\"/ sw/share/openvrml\" -DBOOST_SPIRIT_THREADSAFE - DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 -MT openvrml/exposedfield.lo -MD -MP -MF "$depbase.Tpo" -c -o openvrml/exposedfield.lo openvrml/exposedfield.cpp; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/exposedfield.lo -MD -MP -MF openvrml/.deps/ exposedfield.Tpo -c openvrml/exposedfield.cpp -fno-common -DPIC -o openvrml/.libs/exposedfield.o g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/exposedfield.lo -MD -MP -MF openvrml/.deps/ exposedfield.Tpo -c openvrml/exposedfield.cpp -o openvrml/ exposedfield.o >/dev/null 2>&1 depbase=`echo openvrml/scope.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \ if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java -I../../src/ libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" -DOPENVRML_PKGDATADIR_=\"/ sw/share/openvrml\" -DBOOST_SPIRIT_THREADSAFE - DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 -MT openvrml/scope.lo -MD -MP -MF "$depbase.Tpo" -c -o openvrml/ scope.lo openvrml/scope.cpp; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/scope.lo -MD -MP -MF openvrml/.deps/scope.Tpo -c openvrml/ scope.cpp -fno-common -DPIC -o openvrml/.libs/scope.o g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/scope.lo -MD -MP -MF openvrml/.deps/scope.Tpo -c openvrml/ scope.cpp -o openvrml/scope.o >/dev/null 2>&1 depbase=`echo openvrml/node.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \ if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java -I../../src/ libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" -DOPENVRML_PKGDATADIR_=\"/ sw/share/openvrml\" -DBOOST_SPIRIT_THREADSAFE - DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 -MT openvrml/node.lo -MD -MP -MF "$depbase.Tpo" -c -o openvrml/ node.lo openvrml/node.cpp; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java - I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" - DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" - DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS - DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/ X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 - DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 - MT openvrml/node.lo -MD -MP -MF openvrml/.deps/node.Tpo -c openvrml/ node.cpp -fno-common -DPIC -o openvrml/.libs/node.o /var/tmp//cc7pQI6V.s:unknown:Non-global symbol: __ZTv0_n12_ZN46_GLOBAL__N_openvrml_node.cpp_00000000_0CF9259613self_ref_ node17do_event_listenerERKSsEN14dummy_listenerD1Ev.eh can't be a weak_definition /var/tmp//cc7pQI6V.s:unknown:Non-global symbol: __ZTv0_n12_ZN46_GLOBAL__N_openvrml_node.cpp_00000000_0CF9259613self_ref_ node17do_event_listenerERKSsEN14dummy_listenerD0Ev.eh can't be a weak_definition /var/tmp//cc7pQI6V.s:unknown:Non-global symbol: __ZTv0_n16_ZN46_GLOBAL__N_openvrml_node.cpp_00000000_0CF9259613self_ref_ node16do_event_emitterERKSsENK13dummy_emitter14do_eventout_idEv.eh can't be a weak_definition make[4]: *** [openvrml/node.lo] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ### execution of make failed, exit code 2 ### execution of /var/tmp/tmp.4.mtjDNn failed, exit code 2 |
|
From: Braden M. <br...@en...> - 2006-11-24 04:13:08
|
Quoting Philip Lamb <ph...@ed...>:
> I finally got around to building OpenVRML on Mac OS X on a PowerPC
> machine, and have encountered a build failure during linking. This
> doesn't appear on Mac OS X x86 and I'm at a bit of a loss to diagnose
> the cause:
[snip]
> g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/antlr -I../../java -
> I../../src/libopenvrml -DOPENVRML_LIBDIR_=\"/sw/lib\" -
> DOPENVRML_PKGDATADIR_=\"/sw/share/openvrml\" -
> DBOOST_SPIRIT_THREADSAFE -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -
> DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -I/sw/include -D_THREAD_SAFE -I/usr/
> X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -
> DXP_UNIX -I/sw/include/mozilla/nspr -I/sw/include/mozilla/js -g -O2 -
> MT openvrml/node.lo -MD -MP -MF openvrml/.deps/node.Tpo -c openvrml/
> node.cpp -fno-common -DPIC -o openvrml/.libs/node.o
> /var/tmp//cc7pQI6V.s:unknown:Non-global symbol:
> __ZTv0_n12_ZN46_GLOBAL__N_openvrml_node.cpp_00000000_0CF9259613self_ref_
> node17do_event_listenerERKSsEN14dummy_listenerD1Ev.eh can't be a
> weak_definition
> /var/tmp//cc7pQI6V.s:unknown:Non-global symbol:
> __ZTv0_n12_ZN46_GLOBAL__N_openvrml_node.cpp_00000000_0CF9259613self_ref_
> node17do_event_listenerERKSsEN14dummy_listenerD0Ev.eh can't be a
> weak_definition
> /var/tmp//cc7pQI6V.s:unknown:Non-global symbol:
> __ZTv0_n16_ZN46_GLOBAL__N_openvrml_node.cpp_00000000_0CF9259613self_ref_
> node16do_event_emitterERKSsENK13dummy_emitter14do_eventout_idEv.eh
> can't be a weak_definition
Looks related to symbol visibility. Hard to say exactly what might fix it, but
here are a few things you can try:
* Remove OPENVRML_LOCAL from the definition of self_ref_node.
* Move self_ref_node out of the unnamed namespace.
* Move the definitions of dummy_listener and dummy_emitter out of the
function definitions.
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: Philip L. <ph...@ed...> - 2006-12-01 00:58:29
|
On 25/11/2006, at 11:48 AM, Thomas Engelmeier wrote:
>
> On 23.11.2006, at 20:20, Philip Lamb wrote:
>
>> Hi all,
>>
>> I finally got around to building OpenVRML on Mac OS X on a PowerPC
>> machine, and have encountered a build failure during linking. This
>> doesn't appear on Mac OS X x86 and I'm at a bit of a loss to diagnose
>> the cause:
>
> I messed around with it some months ago. I don=B4t have the fixed =20
> source at hand, but IIRC fix to link
>
> te$ c++filt =20
> _ZTv0_n16_ZN46_GLOBAL__N_openvrml_node.cpp_00000000_0CF9259613self_ref=20=
> _node16do_event_emitterERKSsENK13dummy_emitter14do_eventout_idEv
>
> =3D>
>
> virtual thunk to (anonymous =20
> namespace)::self_ref_node::do_event_emitter(std::basic_string<char, =20=
> std::char_traits<char>, std::allocator<char> > =20
> const&)::dummy_emitter::do_eventout_id() const
>
> was to move the inner, local classes dummy_emitter and =20
> dummy_listener to static local file scope...
OK, thanks for the tip. I have just tested it and it appears to be =20
effective.
So the current state of my patch file to get OpenVRML 0.16.2 to build =20=
for Mac OS X is:
=3D=3D=3D=3D=3D=3D BEGIN PATCH FILE =3D=3D=3D=3D=3D=3D=3D
diff -urN openvrml-0.16.2/src/libopenvrml/openvrml/node.cpp =20
openvrml-0.16.2.patched/src/libopenvrml/openvrml/node.cpp
--- openvrml-0.16.2/src/libopenvrml/openvrml/node.cpp 2006-10-23 =20
19:37:26.000000000 +1300
+++ openvrml-0.16.2.patched/src/libopenvrml/openvrml/node.cpp =20
2006-12-01 12:54:39.000000000 +1300
@@ -1641,6 +1641,31 @@
* @brief <code>mfvec3f</code> <code>exposedfield</code>.
*/
+class dummy_emitter : public openvrml::sfbool_emitter {
+public:
+ explicit dummy_emitter(const openvrml::sfbool & value):
+ openvrml::event_emitter(value),
+ openvrml::sfbool_emitter(value)
+ {}
+
+private:
+ virtual const std::string do_eventout_id() const =20
OPENVRML_NOTHROW
+ {
+ return std::string();
+ }
+};
+
+class dummy_listener : public openvrml::sfbool_listener {
+public:
+ virtual ~dummy_listener() OPENVRML_NOTHROW
+ {}
+
+private:
+ virtual void do_process_event(const openvrml::sfbool &, double)
+ OPENVRML_THROW1(std::bad_alloc)
+ {}
+};
+
namespace {
class OPENVRML_LOCAL self_ref_node : public openvrml::node {
@@ -1686,17 +1711,6 @@
self_ref_node::do_event_listener(const std::string &)
OPENVRML_THROW1(openvrml::unsupported_interface)
{
- class dummy_listener : public openvrml::sfbool_listener {
- public:
- virtual ~dummy_listener() OPENVRML_NOTHROW
- {}
-
- private:
- virtual void do_process_event(const openvrml::sfbool &, =20
double)
- OPENVRML_THROW1(std::bad_alloc)
- {}
- };
-
static dummy_listener listener;
return listener;
}
@@ -1705,20 +1719,6 @@
self_ref_node::do_event_emitter(const std::string &)
OPENVRML_THROW1(openvrml::unsupported_interface)
{
- class dummy_emitter : public openvrml::sfbool_emitter {
- public:
- explicit dummy_emitter(const openvrml::sfbool & value):
- openvrml::event_emitter(value),
- openvrml::sfbool_emitter(value)
- {}
-
- private:
- virtual const std::string do_eventout_id() const =20
OPENVRML_NOTHROW
- {
- return std::string();
- }
- };
-
openvrml::sfbool val;
static dummy_emitter emitter(val);
return emitter;
diff -urN openvrml-0.16.2/src/libopenvrml-gl/openvrml/gl/viewer.cpp =20
openvrml-0.16.2.patched/src/libopenvrml-gl/openvrml/gl/viewer.cpp
--- openvrml-0.16.2/src/libopenvrml-gl/openvrml/gl/viewer.cpp =20
2006-10-11 13:54:31.000000000 +1300
+++ openvrml-0.16.2.patched/src/libopenvrml-gl/openvrml/gl/=20
viewer.cpp 2006-12-01 11:43:13.000000000 +1300
@@ -1971,7 +1971,7 @@
* As the type of callback functions given to OpenGL, this type =20=
must have
* C linkage.
*/
- typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)();
+ typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)(...);
/**
* @internal
@@ -2043,7 +2043,8 @@
reinterpret_cast<TessCB>=20
(tessExtrusionBegin));
gluTessCallback(&tesselator, GLU_TESS_VERTEX_DATA,
reinterpret_cast<TessCB>=20
(tessExtrusionVertex));
- gluTessCallback(&tesselator, GLU_TESS_END, glEnd);
+ gluTessCallback(&tesselator, GLU_TESS_END,
+ =20
reinterpret_cast<GLvoid (*)(...)>(glEnd));
if (mask & viewer::mask_bottom) {
TessExtrusion bottom(&c[0][0],
=3D=3D=3D=3D=3D=3D END PATCH FILE =3D=3D=3D=3D=3D=3D=3D
Many thanks,
Phil.
|
|
From: Braden M. <br...@en...> - 2006-12-07 09:23:35
|
On Fri, 2006-12-01 at 13:57 +1300, Philip Lamb wrote: [snip] > So the current state of my patch file to get OpenVRML 0.16.2 to build > for Mac OS X is: I'm glad you got it working. Am I correct in assuming that Fink accommodates patching pristine sources as part of the packaging process? As long as that's possible, I don't perceive a pressing need to integrate these changes into the official sources. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Thomas E. <te-...@en...> - 2006-12-07 09:44:53
|
On 07.12.2006, at 10:23, Braden McDaniel wrote: >> So the current state of my patch file to get OpenVRML 0.16.2 to build >> for Mac OS X is: > > I'm glad you got it working. Am I correct in assuming that Fink > accommodates patching pristine sources as part of the packaging > process? > > As long as that's possible, I don't perceive a pressing need to > integrate these changes into the official sources. Well, not everyone on OS X uses fink and the patches don't hurt on any compiler anyway (I am not sure if inner classes like used unpatched are guaranteed to work according to the standard, and if it's just Apple's GCC variant that mocks up due to an ABI that can't handle them or if it's an general gcc problem...) Best regards, Tom_E |
|
From: Braden M. <br...@en...> - 2006-12-07 16:03:57
|
On Thu, 2006-12-07 at 10:44 +0100, Thomas Engelmeier wrote: > On 07.12.2006, at 10:23, Braden McDaniel wrote: > > >> So the current state of my patch file to get OpenVRML 0.16.2 to build > >> for Mac OS X is: > > > > I'm glad you got it working. Am I correct in assuming that Fink > > accommodates patching pristine sources as part of the packaging > > process? > > > > As long as that's possible, I don't perceive a pressing need to > > integrate these changes into the official sources. > > Well, not everyone on OS X uses fink and the patches don't hurt on > any compiler anyway (I am not sure if inner classes like used > unpatched are guaranteed to work according to the standard, C++ supports defining classes in function definitions. And that's used other places in OpenVRML; so I'm pretty sure the problem with this bit of code is more subtle than just that. Moving these class definitions out of the function definitions was just one of the three suggestions I gave; were the other two suggestions ineffective? > and if > it's just Apple's GCC variant that mocks up due to an ABI that can't > handle them or if it's an general gcc problem...) FWIW, there apparently is no problem building on PPC for Fedora Core 6, which uses Red Hat's gcc 4.1.1. Part of the problem is that the patch as currently given exposes symbols that weren't exposed before. That's not something I'd like to introduce everywhere. My preferred alternative to defining them locally would be to define them as OPENVRML_LOCAL in the unnamed namespace--if that works. If the symbols *must* be visible on OS X, I'd want to make the code conditional--which means that the compiler problem needs to be sufficiently understood that a configure test can be written to detect it. With regard to the GL-related changes in the patch, I think the issue is even more complicated. My understanding is that there are three or more potential sources for glu.h on an OS X system--and most of them *don't* exhibit the problem that the patch accommodates. I'm not certain, but I think this particular problem is, more or less, Fink-specific. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Thomas E. <te-...@en...> - 2006-12-07 18:08:25
|
On 07.12.2006, at 17:03, Braden McDaniel wrote: >>> As long as that's possible, I don't perceive a pressing need to >>> integrate these changes into the official sources. >> >> Well, not everyone on OS X uses fink and the patches don't hurt on >> any compiler anyway (I am not sure if inner classes like used >> unpatched are guaranteed to work according to the standard, > > C++ supports defining classes in function definitions. And that's used > other places in OpenVRML; so I'm pretty sure the problem with this bit > of code is more subtle than just that. At least it is a long going problem on OS X and chances are little it's gonna be fixed. When I was researching for an fix half an year ago I found traces of that error (but no fix) some years back, which was IIRC shortly after OS X 10.1 was released... > Moving these class definitions out of the function definitions was > just > one of the three suggestions I gave; were the other two suggestions > ineffective? The OP is someone different ;-) so I cannot comment on that. >> and if >> it's just Apple's GCC variant that mocks up due to an ABI that can't >> handle them or if it's an general gcc problem...) > > FWIW, there apparently is no problem building on PPC for Fedora > Core 6, > which uses Red Hat's gcc 4.1.1. Well, Apple apparently uses the Mach-O symbol format (that is pretty lame for register-rich RISC processors) and not PEF or ELF, I guess it's a linker and symbol decoration problem... > Part of the problem is that the patch as currently given exposes > symbols > that weren't exposed before. That's not something I'd like to > introduce > everywhere. IIRC, it is sufficent to expose the symbols as a *static* (local) class in an compilation unit. Well that exposes the symbol just to a handful functions more in the same compilation unit... > With regard to the GL-related changes in the patch, I think the > issue is > even more complicated. My understanding is that there are three or > more > potential sources for glu.h on an OS X system--and most of them > *don't* > exhibit the problem that the patch accommodates. I'm not certain, > but I > think this particular problem is, more or less, Fink-specific. It is definitely not fink but OS X specific. My attempt (once again, long before that patch) was not based on fink, and I also had to fix quite some other opensource gl based projects in the same manner Best regards, Tom_E |
|
From: Braden M. <br...@en...> - 2006-12-08 02:27:52
|
On Thu, 2006-12-07 at 19:08 +0100, Thomas Engelmeier wrote: > On 07.12.2006, at 17:03, Braden McDaniel wrote: > > >>> As long as that's possible, I don't perceive a pressing need to > >>> integrate these changes into the official sources. > >> > >> Well, not everyone on OS X uses fink and the patches don't hurt on > >> any compiler anyway (I am not sure if inner classes like used > >> unpatched are guaranteed to work according to the standard, > > > > C++ supports defining classes in function definitions. And that's used > > other places in OpenVRML; so I'm pretty sure the problem with this bit > > of code is more subtle than just that. > > At least it is a long going problem on OS X and chances are little > it's gonna be fixed. > When I was researching for an fix half an year ago I found traces of > that error (but no fix) some years back, which was IIRC shortly after > OS X 10.1 was released... And PPC Mac is a legacy product at this point, so that can't help. > > Moving these class definitions out of the function definitions was > > just > > one of the three suggestions I gave; were the other two suggestions > > ineffective? > > The OP is someone different ;-) so I cannot comment on that. Well, anyone willing and able to this can comment on it. > >> and if > >> it's just Apple's GCC variant that mocks up due to an ABI that can't > >> handle them or if it's an general gcc problem...) > > > > FWIW, there apparently is no problem building on PPC for Fedora > > Core 6, > > which uses Red Hat's gcc 4.1.1. > > Well, Apple apparently uses the Mach-O symbol format (that is pretty > lame for register-rich RISC processors) and not PEF or ELF, I guess > it's a linker and symbol decoration problem... > > > Part of the problem is that the patch as currently given exposes > > symbols > > that weren't exposed before. That's not something I'd like to > > introduce > > everywhere. > > IIRC, it is sufficent to expose the symbols as a *static* (local) > class in an compilation unit. Well that exposes the symbol just to a > handful functions more in the same compilation unit... "static" in C++ is deprecated for the purpose of specifying internal linkage; as such, it isn't used in OpenVRML. Symbols local to the translation unit are put in unnamed namespaces. Before I change anything, I'd like to understand exactly what the problem is; that's why I'm interested in the results of my other suggestions. I want to know what effect the unnamed namespace has and what effect OPENVRML_LOCAL has. > > With regard to the GL-related changes in the patch, I think the > > issue is > > even more complicated. My understanding is that there are three or > > more > > potential sources for glu.h on an OS X system--and most of them > > *don't* > > exhibit the problem that the patch accommodates. I'm not certain, > > but I > > think this particular problem is, more or less, Fink-specific. > > It is definitely not fink but OS X specific. My attempt (once again, > long before that patch) was not based on fink, and I also had to fix > quite some other opensource gl based projects in the same manner Well, I spoke with a Mac user on IRC some weeks ago and the glu.h he was able to locate on his system did not exhibit this breakage. I don't know exactly which glu.h he found. (I thought it was the one associated with the OpenGL framework, but maybe not.) As I understand it, you can get one from the normal Apple OpenGL framework, one from Apple's X11, and one from Fink's X11. So, the question is, which header (or headers) are broken? -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Thomas E. <te-...@en...> - 2006-12-08 11:39:20
|
On 08.12.2006, at 03:27, Braden McDaniel wrote: > Well, I spoke with a Mac user on IRC some weeks ago and the glu.h > he was > able to locate on his system did not exhibit this breakage. I don't > know > exactly which glu.h he found. (I thought it was the one associated > with > the OpenGL framework, but maybe not.) As I understand it, you can get > one from the normal Apple OpenGL framework, one from Apple's X11, and > one from Fink's X11. So, the question is, which header (or headers) > are > broken? In my case it is the official system header <OpenGL/glu.h> from the 10.4.u SDK (which is identical to the 10.3.9 SDK). The X11 SDK and fink are not installed. The copyright note in it indicates it dates to 1999 gluTessCallback is declared there (identical to my 1992 red book) as extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)()); Best regards, Thomas |
|
From: Braden M. <br...@en...> - 2006-12-08 14:44:55
|
On Fri, 2006-12-08 at 12:39 +0100, Thomas Engelmeier wrote:
> On 08.12.2006, at 03:27, Braden McDaniel wrote:
>
> > Well, I spoke with a Mac user on IRC some weeks ago and the glu.h
> > he was
> > able to locate on his system did not exhibit this breakage. I don't
> > know
> > exactly which glu.h he found. (I thought it was the one associated
> > with
> > the OpenGL framework, but maybe not.) As I understand it, you can get
> > one from the normal Apple OpenGL framework, one from Apple's X11, and
> > one from Fink's X11. So, the question is, which header (or headers)
> > are
> > broken?
>
> In my case it is the official system header <OpenGL/glu.h> from the
> 10.4.u SDK (which is identical to the 10.3.9 SDK). The X11 SDK and
> fink are not installed. The copyright note in it indicates it dates
> to 1999
>
> gluTessCallback is declared there (identical to my 1992 red book) as
>
> extern void gluTessCallback (GLUtesselator* tess, GLenum which,
> GLvoid (*CallBackFunc)());
Then you should not be observing this problem. (And in fact, I'd expect
the patch applied for Fink to cause things to break when built against
that header.) The problem is with glu.h where the declaration of
gluTessCallback looks like this:
void gluTessCallback(GLUtesselator* tess, GLenum which,
GLvoid (*CallBackFunc)(...));
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: Philip L. <ph...@ed...> - 2006-12-08 22:24:52
|
On 09/12/2006, at 3:44 AM, Braden McDaniel wrote: > On Fri, 2006-12-08 at 12:39 +0100, Thomas Engelmeier wrote: >> On 08.12.2006, at 03:27, Braden McDaniel wrote: >> >>> Well, I spoke with a Mac user on IRC some weeks ago and the glu.h >>> he was >>> able to locate on his system did not exhibit this breakage. I don't >>> know >>> exactly which glu.h he found. (I thought it was the one associated >>> with >>> the OpenGL framework, but maybe not.) As I understand it, you can >>> get >>> one from the normal Apple OpenGL framework, one from Apple's X11, >>> and >>> one from Fink's X11. So, the question is, which header (or headers) >>> are >>> broken? >> >> In my case it is the official system header <OpenGL/glu.h> from the >> 10.4.u SDK (which is identical to the 10.3.9 SDK). The X11 SDK and >> fink are not installed. The copyright note in it indicates it dates >> to 1999 >> >> gluTessCallback is declared there (identical to my 1992 red book) as >> >> extern void gluTessCallback (GLUtesselator* tess, GLenum which, >> GLvoid (*CallBackFunc)()); > > Then you should not be observing this problem. (And in fact, I'd > expect > the patch applied for Fink to cause things to break when built against > that header.) The problem is with glu.h where the declaration of > gluTessCallback looks like this: > > void gluTessCallback(GLUtesselator* tess, GLenum which, > GLvoid (*CallBackFunc)(...)); > Nowhere in any of the glu.h headers on the system is it declared in this way. I'm still not sure that this is a problem with the headers. % locate glu.h | xargs grep gluTessCallback /Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/ AGL.framework/Versions/A/Headers/glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)()); /Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/ OpenGL.framework/Versions/A/Headers/glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)()); /Developer/SDKs/MacOSX10.3.9.sdk/usr/X11R6/include/GL/glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, _GLUfuncptr CallBackFunc); /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/ AGL.framework/Versions/A/Headers/glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)()); /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/ OpenGL.framework/Versions/A/Headers/glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)()); /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/GL/glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, _GLUfuncptr CallBackFunc); /System/Library/Frameworks/AGL.framework/Versions/A/Headers/ glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)()); /System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/ glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)()); /usr/X11R6/include/GL/glu.h:extern void gluTessCallback (GLUtesselator* tess, GLenum which, _GLUfuncptr CallBackFunc); and: %grep _GLUfuncptr /usr/X11R6/include/GL/glu.h /usr/X11R6/include/GL/glu.h:typedef GLvoid (*_GLUfuncptr)(); /usr/X11R6/include/GL/glu.h:typedef GLvoid (*_GLUfuncptr)(GLvoid); Phil. |
|
From: Philip L. <ph...@ed...> - 2006-12-08 22:42:01
|
On 07/12/2006, at 10:23 PM, Braden McDaniel wrote: > On Fri, 2006-12-01 at 13:57 +1300, Philip Lamb wrote: > > [snip] > >> So the current state of my patch file to get OpenVRML 0.16.2 to build >> for Mac OS X is: > > I'm glad you got it working. Am I correct in assuming that Fink > accommodates patching pristine sources as part of the packaging > process? > > As long as that's possible, I don't perceive a pressing need to > integrate these changes into the official sources. Yes, fink accommodates patching of unmodified sources as part of the build process. However, I'm not so sure I believe in your philosophy with regards to where build issues on any given platform should be accommodated, Braden. We can either deal with the API and environment as it is, or as we wish it was. Idealism is rarely productive in software development. Accommodating these particular bugs/peculiarities/ whatevers is as simple as putting an #ifdef __APPLE__ into the code. Phil. |
|
From: Braden M. <br...@en...> - 2006-12-09 06:28:47
|
On Sat, 2006-12-09 at 11:41 +1300, Philip Lamb wrote: > On 07/12/2006, at 10:23 PM, Braden McDaniel wrote: > > > On Fri, 2006-12-01 at 13:57 +1300, Philip Lamb wrote: > > > > [snip] > > > >> So the current state of my patch file to get OpenVRML 0.16.2 to build > >> for Mac OS X is: > > > > I'm glad you got it working. Am I correct in assuming that Fink > > accommodates patching pristine sources as part of the packaging > > process? > > > > As long as that's possible, I don't perceive a pressing need to > > integrate these changes into the official sources. > > Yes, fink accommodates patching of unmodified sources as part of the > build process. > > However, I'm not so sure I believe in your philosophy with regards to > where build issues on any given platform should be accommodated, > Braden. We can either deal with the API and environment as it is, or > as we wish it was. Idealism is rarely productive in software > development. Pragmatically, less conditional code in OpenVRML means less code to bit-rot when I can't test it regularly. If you look at the OpenVRML sources, you will find platform-specific accommodations. But they really are a means of last resort; because they do make maintenance more difficult. As such, I usually try to find another way. With respect to something like Fink, I am generally of the opinion that problems introduced by Fink should be solved on the Fink end of things--to the extent that they can be. Same goes for problems introduced by the particular ways different Linux distributions do things. But that's neither here nor there as it's become apparent to me that the problems addressed by your patch are not Fink-specific. > Accommodating these particular bugs/peculiarities/ > whatevers is as simple as putting an #ifdef __APPLE__ into the code. Right now I have no confidence that the GLU callback issue can be resolved in that manner; I do not know that it would be robust in the face of someone attempting to compile OpenVRML against the glu.h associated with Apple's X11 or Fink's X11. If this problem is unique to the headers associated with Apple's OpenGL framework, then the symbol HAVE_APPLE_OPENGL_FRAMEWORK can be used. If it's more complicated than that, then I probably need to write a configure test to diagnose the issue. In order to do that, I need to know why it's happening. With regard to the other issue involving the locally defined classes, I will commit a change to OpenVRML to move those classes into the unnamed namespace. I suspect that will solve the problem. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Braden M. <br...@en...> - 2006-12-09 04:08:18
|
On Sat, 2006-12-09 at 11:24 +1300, Philip Lamb wrote:
> On 09/12/2006, at 3:44 AM, Braden McDaniel wrote:
[snip]
> > void gluTessCallback(GLUtesselator* tess, GLenum which,
> > GLvoid (*CallBackFunc)(...));
> >
>
> Nowhere in any of the glu.h headers on the system is it declared in
> this way. I'm still not sure that this is a problem with the headers.
Puzzling. What, then, is the source of the problem? That is, what's
making the compiler think the callback function signature is
GLvoid (*)(...)
when all indications are that it should be
GLvoid (*)()
???
Do you (or any other Mac users reading) recall experiencing something
like this outside the context of OpenGL? Is there other C++ software
using the GLU callbacks that successfully compiles using the latter
signature?
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: Braden M. <br...@en...> - 2006-12-09 08:02:07
|
I've managed to locate a PPC Mac where I can test this a bit. For those
of you playing along with the home game, try this...
Go to line 290
of /System/Library/Frameworks/OpenGL.framework/Headers/glu.h. You should
find the declaration of gluTessCallback there; note that it's inside an
extern "C" block. Copy the declaration of gluTessCallback.
Now go to src/libopenvrml-gl/openvrml/gl/viewer.cpp. Create an extern
"C" block after <OpenGL/glu.h> is included and paste the definition of
gluTessCallback there. You should wind up with something that looks like
this:
# if HAVE_APPLE_OPENGL_FRAMEWORK
# include <OpenGL/gl.h>
# include <OpenGL/glu.h>
# else
# include <GL/gl.h>
# include <GL/glu.h>
# endif
extern "C" {
extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)());
}
Now compile. Here's what you get:
../../../src/libopenvrml-gl/openvrml/gl/viewer.cpp:42: error: declaration of C function 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())' conflicts with
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:290: error: previous declaration 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))' here
WTF??? That is some first class brain damage there.
I know nothing about how frameworks work on Mac OS X; but I can only
guess from this behavior that the compiler is checking something *other*
than the source code (i.e., glu.h) for the type associated with the
external symbol--presumably some sort of manifest associated with the
framework.
Clues welcome.
In the absence of further input with a better suggestion, I'm going to
make the declaration of TessCB dependent on HAVE_APPLE_OPENGL_FRAMEWORK:
# if HAVE_APPLE_OPENGL_FRAMEWORK
typedef GLvoid (*OPENVRML_GL_CALLBACK_ TessCB)(...);
# else
typedef GLvoid (*OPENVRML_GL_CALLBACK_ TessCB)(GLvoid);
# endif
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X