openvrml-develop — OpenVRML developers mailing list

[openvrml-develop] Status: openvrml-player

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

Debugging OpenVRML's resource loading in the Mozilla plug-in has made it
clear to me that I need a more convenient way of doing that. The Web
browser is a heavy piece of machinery that tends to get in the way when
trying to pinpoint a problem. It would also help to have something that
just works a bit differently in order to better sanity-check the code in
libopenvrml.

That is the self-interested reason for introducing a stand-alone viewer;
though I suspect a number of users would find this convenient as well
for their own reasons.

Like the Mozilla plug-in, openvrml-player--the stand-alone viewer--will
simply be a front-end to openvrml-gtkplug. It will use GTK/GNOME for its
user interface and libcurl for resource fetching.

I'm probably still a few weeks away from checking anything in; but the
current plan is for this to go into 0.16.3.

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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.

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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.

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

[Thomas E. <te-...@en...>]

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

[Thomas E. <te-...@en...>]

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

[Thomas E. <te-...@en...>]

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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.

[openvrml-develop] ANN: OpenVRML 0.16.2

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

OpenVRML 0.16.2 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.16.2.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes a Mozilla browser plug-in.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.16.2:

- Fixed the parsers to use the user-supplied std::ostream consistently
  for error and warning output.

- Fixed the parser error and warning output to report line and column
  number information more consistently and accurately.

- Fixed the build system such that a failure to find all of GtkGLExt's
  prerequisites will not cause configure to fail.

- Fixed the build system to better accommodate a user-supplied antlr
  executable.

[openvrml-develop] OpenVRML in Fedora Extras

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

OpenVRML is now available in Fedora Extras, the more-or-less official repository
of add-on packages for Fedora Core.

As such, I intend to stop maintaining the RPM spec file as part of the OpenVRML
distribution and to stop distributing RPMs for future releases via SourceForge.
(Because those who want RPMs for Fedora will be able to get them from Fedora
Extras; and those who want to modify the spec file for use with other RPM-based
distributions can get it from Fedora Extras CVS.)

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

Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

[openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

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

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

Re: [openvrml-develop] Error loading vrml with 0.16.1, worked OK with 0.15.10

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

On Thu, 2006-11-16 at 16:46 +1300, Philip Lamb wrote:
> Hi all,
> 
> I am loading a vrml file with OpenVRML (using sdl-viewer) that loads  
> OK in 0.15.10, but on 0.16.1 bails out with this error:
> 
> openvrml/basetypes.cpp:2619: failed assertion `axis == axis.normalize()'
> 
> Is there any way to force openvrml to ignore these kinds of  
> assertions???

This should be fixed now; both on MAIN and the OpenVRML-0_16-BRANCH. The
fix will appear in 0.16.2.

At the moment I'm in the final stages of getting 0.16.1 into Fedora
Extras. I feel like there are enough interesting fixes on the
OpenVRML-0_16-BRANCH to warrant 0.16.2; so the next item of business
will be making that release.

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

[openvrml-develop] Crash-on-exit versus API change

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

I've got a fix for bug 1530554[1] nearly ready to commit.  This one was
particularly annoying to me since it produced random failures in "make
check".

The bad news is that the fix required an API change. That means the fix
won't appear in a release until 0.17.0.

I have quite a few irons in the fire; but right now, the trunk doesn't
have much in the way of functional changes. Per my previous postings on
the topic, I've been planning to hold 0.17 until the modularization work
is done--and that's still some months away. However, if fixing this
crash is important enough that a release be made with the fix ASAP, the
modularization stuff can wait for 0.18.

Applications are only likely to hit this bug if the browser gets
destroyed in the middle of fetching a resource. So, if anyone's hit
this, or thinks they could do so easily, please speak up.

[1] http://sourceforge.net/tracker/index.php?func=detail&aid=1530554&group_id=7151&atid=107151

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

Re: [openvrml-develop] stripping libopenvrml.a

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

On Mon, 2006-11-20 at 00:46 +0100, Stefan Rilling wrote:

> I compiled openVRML with both Cygwin and MinGW and tried to strip it,
> with similar failures. I also think I would have to make some major changes
> to the Makefile to compile it with the Visual C++ compiler, and as I
> am usually developing with MinGW, I would prefer to avoid this
> opportunity.

The OpenVRML distribution includes project files for Visual C++ 2005.

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

Re: [openvrml-develop] stripping libopenvrml.a

[Stefan R. <ste...@gm...>]

Hello,

Sunday, November 19, 2006, 7:43:12 PM, you wrote:

RH> Reed Hedges wrote:
>> Braden McDaniel wrote:
>> 
>>> You could not use Cygwin/gcc. gcc doesn't handle lots of large symbols
>> 
>>> Can you use the Microsoft compiler?
>> 
>> I usually prefer MinGW (with MSYS), though I've never tried Openvrml
>> with it.

RH> It may have similar problems, since the gcc port is similar (though the
RH> libraries are not)

I compiled openVRML with both Cygwin and MinGW and tried to strip it,
with similar failures. I also think I would have to make some major changes
to the Makefile to compile it with the Visual C++ compiler, and as I
am usually developing with MinGW, I would prefer to avoid this
opportunity. So are there any other options for me to make the library
smaller or do I have to get used to this?

-- 
Thanks for the answers,
 Stefan                          

Re: [openvrml-develop] stripping libopenvrml.a

[Reed H. <re...@in...>]

Reed Hedges wrote:
> Braden McDaniel wrote:
> 
>> You could not use Cygwin/gcc. gcc doesn't handle lots of large symbols
> 
>> Can you use the Microsoft compiler?
> 
> I usually prefer MinGW (with MSYS), though I've never tried Openvrml
> with it.

It may have similar problems, since the gcc port is similar (though the
libraries are not)

Reed

Re: [openvrml-develop] stripping libopenvrml.a

[Reed H. <re...@in...>]

Braden McDaniel wrote:

> You could not use Cygwin/gcc. gcc doesn't handle lots of large symbols

> Can you use the Microsoft compiler?

I usually prefer MinGW (with MSYS), though I've never tried Openvrml
with it.

Reed

Re: [openvrml-develop] stripping libopenvrml.a

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

On Sun, 2006-11-19 at 00:00 +0100, Stefan Rilling wrote:
> Hello,
> 
> BM> Stripping a static library is a little unusual; and you might have to
> BM> play with some of the options to strip to see what works. Read "man
> BM> strip". You definitely don't want to strip *everything*; I'd start with
> BM> --strip-unneeded.
> I forgot to mention that I already tried all the options strip offers.
> both --strip-unneeded and --discard-all give me the error:
> BFD: BFD 2.15.91 20040904 internal error, aborting at ../../src/bfd/coffcode.h l
> ine 852 in handle_COMDAT
> 
> BFD: Please report this bug.

Bummer. Oh, well. It's Cygwin.

> --discard-locals and --strip-debug do not reduce the size nameable.
> The problem with the size of libopenvrml.a I have is that the linking
> process for my app takes about 10 minutes, and as I'm quite new to
> openVRML, I have to recompile very often to try different things. So
> do I have any other chances to speed up linking instead of striping
> the library?

You could not use Cygwin/gcc. gcc doesn't handle lots of large symbols
particularly well on any platform--though this is improving. (The Red
Hat variant of gcc 4.1.1 that ships with Fedora Core 6 includes
improvements that make compiling/linking OpenVRML *fly* relative to
previous releases.) In general, if something is slow, doing it on Cygwin
will make it even slower.

Can you use the Microsoft compiler?

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