openvrml-develop — OpenVRML developers mailing list

Re: [openvrml-develop] Status update: modularization

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

On Mon, 2006-10-23 at 02:36 +0200, Josip Almasi wrote:
> Braden McDaniel wrote:

[snip]

> > At the moment, I'm just planning on running the VM in OpenVRML's main
> > (rendering) thread. I could give the VM its own thread if I need to--and
> > in that case I'd simply use something along the lines of an active
> > object pattern to transmit data--no separate process, so no pipes.
> 
> IOW JNI method calls.
> Well then a nasty script could hang the main thread... or, say, a 
> TimeSensor routed to it?
> ... no big deal, now that I think of it some more.

Right. Scripts block--period. It doesn't matter if they're in another
thread--all that means is that a request is dispatched to the script
thread and the rendering thread has to wait on it to be processed.

> Once you start a jvm it can start its own threads, in fact even java 
> scripts can start their own threads.
> So there's no point in trying to prevent eventual mess a script can do.
> Some reasonable strategy I use in somewhat simillar case is startup in 
> multiple threads, so they can't hang main, and main doesn't have to wait 
> for initialization.
> Applied to vrml java scripts, like,
> if (method initialize() exists) {
>    (new Thread( script )).start()
> } else {
>    try { script.run() } catch ( Throwable t ) {...}
> It's probably overkill for scripts...

Maybe not. Or not quite, anyway.

I ought to spawn a new thread to download the script code, at the very
least; I don't want to have the rendering thread block on that. I
*could* just keep that thread running and run the script in it and do
the active object thing.

I'll have to play around with how all this works. I'm starting to get to
far ahead of myself without having gotten some basic code running.

> > As for loading the classes, I'm under the impression that I can just use
> > URLClassLoader for that. I think I can construct one of these via JNI
> > and tell it to construct an instance of the vrml.node.Script subclass.
> 
> Right, though I'd suggest extending URLClassLoader with some extras.
> Nothing specific so far, but that's why I mention VRSpaceLoader - it 
> extends URLClassLoader too. As do classloaders of tomcat and others.

I've had a brief look; nothing there jumped out at me as being something
I needed. But I'm still pretty naive about a lot of this. Though it has
occurred to me that if I ever want to do something like display download
progress for this stuff, I'll presumably need to implement my own
URLStreamHandler. Joy.

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

Re: [openvrml-develop] Status update: modularization

[Josip A. <jo...@vr...>]

Braden McDaniel wrote:
> 
> You have the opportunity to set the classpath when starting the VM via
> JNI. The semantics of this are the same as the -cp command line argument
> to the java runtime executable; i.e., it overrides the CLASSPATH
> environment variable.
> 
> As such, I'll get the value of CLASSPATH from the environment and
> prepend it to the setting passed to the VM.

OK this should do it.

> A quick experiment demonstrates for me that applets on the same Web page
> run in the same VM. While I question the soundness of that design, I
> know (at least one reason) why they did it: the VM has historically been
> a pig and it's only relatively recently that Sun has begun to optimize
> concurrently running VMs to share resources.

Right, and AFAIK apple did it in their jvm earlier.
In the meantime, there's a number of methods that more or less suck.
But it turns out it's not that unsafe design. These applets can't access 
each other just like that, nor hang each other just like that.
After all, each of them can easy hang the browser so it doesn't matter;)

> At the moment, I'm just planning on running the VM in OpenVRML's main
> (rendering) thread. I could give the VM its own thread if I need to--and
> in that case I'd simply use something along the lines of an active
> object pattern to transmit data--no separate process, so no pipes.

IOW JNI method calls.
Well then a nasty script could hang the main thread... or, say, a 
TimeSensor routed to it?
... no big deal, now that I think of it some more.
Once you start a jvm it can start its own threads, in fact even java 
scripts can start their own threads.
So there's no point in trying to prevent eventual mess a script can do.
Some reasonable strategy I use in somewhat simillar case is startup in 
multiple threads, so they can't hang main, and main doesn't have to wait 
for initialization.
Applied to vrml java scripts, like,
if (method initialize() exists) {
   (new Thread( script )).start()
} else {
   try { script.run() } catch ( Throwable t ) {...}
It's probably overkill for scripts...

> As for loading the classes, I'm under the impression that I can just use
> URLClassLoader for that. I think I can construct one of these via JNI
> and tell it to construct an instance of the vrml.node.Script subclass.

Right, though I'd suggest extending URLClassLoader with some extras.
Nothing specific so far, but that's why I mention VRSpaceLoader - it 
extends URLClassLoader too. As do classloaders of tomcat and others.

Regards...

Re: [openvrml-develop] Status update: modularization

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

On Mon, 2006-10-23 at 00:30 +0200, Josip Almasi wrote:
> Braden McDaniel wrote:
> > At this point I have successfully ported the JavaScript scripting 
> > backend to a dynamically loaded module; it seems to be working just 
> > fine. I would like to take this opportunity to fix the long-ailing Java 
> > scripting engine. I'm just now getting an idea of what I'm in for.
> > 
> > It hasn't been compiling for a while; but that's not the worst of the 
> > problems. It is currently written assuming that all Java scripts in a 
> > world would share the same VM. I don't think that's desirable; and I'm 
> > even less sure that it's workable: it's my understanding that each 
> > vrml.node.Script subclass will need to have its base URI added to the 
> > classpath; and surely different Scripts need to run in isolation from 
> > one another.
> 
> Oh I'm not that sure about that classpath thing. IIRC from the spec, 
> each script needs to have access to full usual java stuff. Like, 
> standard J2SE API.

I see no obvious way to avoid access to the Java standard libraries--and
as you note, I wouldn't want that anyway.

You have the opportunity to set the classpath when starting the VM via
JNI. The semantics of this are the same as the -cp command line argument
to the java runtime executable; i.e., it overrides the CLASSPATH
environment variable.

As such, I'll get the value of CLASSPATH from the environment and
prepend it to the setting passed to the VM.

> The catch is, other components, 'optional' packages may be available 
> too. Like, JMF, J3D, JavaComm etc. We usually enable them by placing 
> them into jre/lib/ext or adding to runtime by java -Djava.ext.dirs=...
> So that's why I call them 'usual' - whatever this specific JVM has 
> installed.
> And you can use that to your advantage - just exec jvm with 
> -Djava.ext.dirs=scripts dir(s). IIRC it has to be defined during JVM 
> bootstrap.
> As for isolating scripts from one another, I think this could be handled 
> by java security manager/policy. Like, you can forbid reflection so an 
> object can't inspect others.

A quick experiment demonstrates for me that applets on the same Web page
run in the same VM. While I question the soundness of that design, I
know (at least one reason) why they did it: the VM has historically been
a pig and it's only relatively recently that Sun has begun to optimize
concurrently running VMs to share resources.

> > So, proceeding with the assumption that we need a VM-per-Script node, 
> > the JNI documentation says that you can have no more than one VM per 
> > thread. That means that the openvrml::script subclass in the Java script 
> >   engine needs to spawn its own thread and function more-or-less as an 
> > active object. This is nontrivial code, none of which is in place.
> 
> I say drop VM-per-Script idea.
> One interpreter to host scripts, that's ok.
> I'll gladly help you with that, in fact I think we can use VRSpaceLoader 
> for starters. That's what it does, loads classes in runtime...
> As for thread-per-script model... sure, it has to be done that way.
> So, say, you spawn a jvm and send/receive events thru a pipe or...?
> Suppose you send events like 'script <id> <eventname> <eventvalue>'.
> There's more vrspace code to handle it, but it's around already.
> And yes it's not trivial...;)

At the moment, I'm just planning on running the VM in OpenVRML's main
(rendering) thread. I could give the VM its own thread if I need to--and
in that case I'd simply use something along the lines of an active
object pattern to transmit data--no separate process, so no pipes.

As for loading the classes, I'm under the impression that I can just use
URLClassLoader for that. I think I can construct one of these via JNI
and tell it to construct an instance of the vrml.node.Script subclass.

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

Re: [openvrml-develop] Status update: modularization

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

On Sat, 2006-10-21 at 19:23 -0400, Reed Hedges wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Braden McDaniel wrote:
> > 
> > So, proceeding with the assumption that we need a VM-per-Script node, 
> > the JNI documentation says that you can have no more than one VM per 
> > thread. That means that the openvrml::script subclass in the Java script 
> >   engine needs to spawn its own thread and function more-or-less as an 
> > active object. This is nontrivial code, none of which is in place.
> > 
> > I'm not throwing my hands up in dismay; but getting 
> > Java-in-the-Script-node working is going to take longer than I'd 
> > anticipated. So while I'd hoped to check in JavaScript and Java 
> > scripting engines at the same time, I'm now leaning toward just checking 
> > in the JavaScript one for now. The Java stuff will most likely be going 
> > away for a little while so I can rework it. Given the time that's 
> > elapsed since anyone tried to compile this, I doubt it will be missed.
> > 
> 
> 
> Have you talked to Peter Amstutz about any of this?  He's working on
> nailing down some issues like this in VOS right now.

I've talked a bit with Peter on IRC. And I've talked to some folks who
know more about Java than I do.

I've come around to the conclusion that each vrml.node.Script does not
need its own VM instance after all. Though there's still plenty of work
to be done to get things working, though. I have toyed with the idea of
going ahead and adding the machinery to support a VM-per-Script;
however, I think I'd end up with a code path that would barely be
used--and I don't want that.

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

Re: [openvrml-develop] Status update: modularization

[Josip A. <jo...@vr...>]

Braden McDaniel wrote:
> At this point I have successfully ported the JavaScript scripting 
> backend to a dynamically loaded module; it seems to be working just 
> fine. I would like to take this opportunity to fix the long-ailing Java 
> scripting engine. I'm just now getting an idea of what I'm in for.
> 
> It hasn't been compiling for a while; but that's not the worst of the 
> problems. It is currently written assuming that all Java scripts in a 
> world would share the same VM. I don't think that's desirable; and I'm 
> even less sure that it's workable: it's my understanding that each 
> vrml.node.Script subclass will need to have its base URI added to the 
> classpath; and surely different Scripts need to run in isolation from 
> one another.

Oh I'm not that sure about that classpath thing. IIRC from the spec, 
each script needs to have access to full usual java stuff. Like, 
standard J2SE API.
The catch is, other components, 'optional' packages may be available 
too. Like, JMF, J3D, JavaComm etc. We usually enable them by placing 
them into jre/lib/ext or adding to runtime by java -Djava.ext.dirs=...
So that's why I call them 'usual' - whatever this specific JVM has 
installed.
And you can use that to your advantage - just exec jvm with 
-Djava.ext.dirs=scripts dir(s). IIRC it has to be defined during JVM 
bootstrap.
As for isolating scripts from one another, I think this could be handled 
by java security manager/policy. Like, you can forbid reflection so an 
object can't inspect others.

> So, proceeding with the assumption that we need a VM-per-Script node, 
> the JNI documentation says that you can have no more than one VM per 
> thread. That means that the openvrml::script subclass in the Java script 
>   engine needs to spawn its own thread and function more-or-less as an 
> active object. This is nontrivial code, none of which is in place.

I say drop VM-per-Script idea.
One interpreter to host scripts, that's ok.
I'll gladly help you with that, in fact I think we can use VRSpaceLoader 
for starters. That's what it does, loads classes in runtime...
As for thread-per-script model... sure, it has to be done that way.
So, say, you spawn a jvm and send/receive events thru a pipe or...?
Suppose you send events like 'script <id> <eventname> <eventvalue>'.
There's more vrspace code to handle it, but it's around already.
And yes it's not trivial...;)

Regards...

Re: [openvrml-develop] Status update: modularization

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Braden McDaniel wrote:
> 
> So, proceeding with the assumption that we need a VM-per-Script node, 
> the JNI documentation says that you can have no more than one VM per 
> thread. That means that the openvrml::script subclass in the Java script 
>   engine needs to spawn its own thread and function more-or-less as an 
> active object. This is nontrivial code, none of which is in place.
> 
> I'm not throwing my hands up in dismay; but getting 
> Java-in-the-Script-node working is going to take longer than I'd 
> anticipated. So while I'd hoped to check in JavaScript and Java 
> scripting engines at the same time, I'm now leaning toward just checking 
> in the JavaScript one for now. The Java stuff will most likely be going 
> away for a little while so I can rework it. Given the time that's 
> elapsed since anyone tried to compile this, I doubt it will be missed.
> 


Have you talked to Peter Amstutz about any of this?  He's working on
nailing down some issues like this in VOS right now.

Reed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFOqvaFK83gN8ItOQRAkfEAJwOSyqbxXHekG5g8WZ4/SdJy1m6HgCeJ/y1
Fc6l3xclLLNhI77b+Gb+uF4=
=F5yZ
-----END PGP SIGNATURE-----

[openvrml-develop] Status update: modularization

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

As I mentioned in a previous update, the primary feature I want to have 
in place for 0.17 is the fragmentation of libopenvrml into dynamically 
loaded modules. I've started some work on this.

There will be two kinds of modules: node components and scripting 
engines. I've started with the latter because it is more obvious to me 
how scripting engine modules should work; node component modules are 
going to require an XML descriptor and inter-component dependencies and 
it's not yet clear to me what the desirable mechanics are for that.

At this point I have successfully ported the JavaScript scripting 
backend to a dynamically loaded module; it seems to be working just 
fine. I would like to take this opportunity to fix the long-ailing Java 
scripting engine. I'm just now getting an idea of what I'm in for.

It hasn't been compiling for a while; but that's not the worst of the 
problems. It is currently written assuming that all Java scripts in a 
world would share the same VM. I don't think that's desirable; and I'm 
even less sure that it's workable: it's my understanding that each 
vrml.node.Script subclass will need to have its base URI added to the 
classpath; and surely different Scripts need to run in isolation from 
one another.

So, proceeding with the assumption that we need a VM-per-Script node, 
the JNI documentation says that you can have no more than one VM per 
thread. That means that the openvrml::script subclass in the Java script 
  engine needs to spawn its own thread and function more-or-less as an 
active object. This is nontrivial code, none of which is in place.

I'm not throwing my hands up in dismay; but getting 
Java-in-the-Script-node working is going to take longer than I'd 
anticipated. So while I'd hoped to check in JavaScript and Java 
scripting engines at the same time, I'm now leaning toward just checking 
in the JavaScript one for now. The Java stuff will most likely be going 
away for a little while so I can rework it. Given the time that's 
elapsed since anyone tried to compile this, I doubt it will be missed.

Braden

Re: [openvrml-develop] OpenVRML-0_16-BRANCH status

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

On Wed, 2006-10-04 at 00:28 -0400, Braden McDaniel wrote:

> I'll probably release 0.16.1 in the next week or so.

Fedora Core 6 is due out this coming week; since I expect some work to
be required to build with it, I'm going to put the 0.16.1 release off
until I can resolve those inevitable issues.

Meanwhile I'm going to purge usage of XPCOM from the Mozilla plug-in,
replacing it with usage of the npruntime extensions to NPAPI.

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

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

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

On Thu, 2006-10-05 at 10:42 +1300, Philip Lamb wrote:

> Finally, one difficulty we are running into on the Intel-based Macs  
> is that the last official mozilla version does not compile on Intel  
> Mac OS X. Our options for the mozilla-1.8 and later branches are  
> firefox and seamonkey. Since the key thing mozilla is needed for on  
> the Mac openvrml builds is script node javascript, I would like to  
> add this back in at some stage. However, fiddling with autoconfig and  
> patching header files is not my idea of fun, so perhaps its something  
> you'd like to consider - the linux builds will eventually run into  
> the same issue, with users preferring firefox and/or seamonkey over  
> an aging mozilla.

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

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

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

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

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

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

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

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

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

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

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

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

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

On Thu, 2006-10-05 at 10:42 +1300, Philip Lamb wrote:
> On 04/10/2006, at 1:37 PM, Braden McDaniel wrote:
> 
> > On Wed, 2006-10-04 at 12:24 +1300, Philip Lamb wrote:
> >> Firstly, I am building from the 0.16.0+cvs, under Mac OS X 10.4.8 on
> >> an Intel MacBook Pro.
> >
> > I hope this means you checked out using the OpenVRML-0_16_0-RELEASE or
> > the OpenVRML-0_16-BRANCH tag.
> >
> 
> No, I was trying to be too clever, and compiling from head. I have  
> reverted now to just the 0.16.0 release tarball, since it simplifies  
> these issues, and is what fink users would get anyway.
> 
> > BTW, configure should be looking for Rez in the spot that you are
> > specifying; thus it should not be necessary to set that environment
> > variable. If it *is* necessary, I'd like to know about it.
> 
> I have let you know this before, but here is the output the autoconf  
> "checking for Rez" step:
> 
> checking for Rez... /sw/bin:/sw/sbin:~/bin/i386-apple-darwin:/Users/ 
> phil/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/ 
> sbin:/usr/X11R6/bin:/Developer/Tools
> 
> i.e. it takes my whole path as the pathname of the rez executable.  
> This fails during the build, since its not a valid path for Rez ;-)

Argh. I goofed and was using the AC_PATH_PROG macro incorrectly. I've
attached a patch that I'll be committing shortly.

> This time, things went OK, except I did need to patch one file in  
> order to keep gcc 4.0.1 happy.
> 
> === PATCH BEGINS ===
> diff -urN openvrml-0.16.0/src/libopenvrml-gl/openvrml/gl/viewer.cpp  
> openvrml-0.16.0.patched/src/libopenvrml-gl/openvrml/gl/viewer.cpp
> --- openvrml-0.16.0/src/libopenvrml-gl/openvrml/gl/viewer.cpp    
> 2006-02-25 21:39:42.000000000 +1300
> +++ openvrml-0.16.0.patched/src/libopenvrml-gl/openvrml/gl/ 
> viewer.cpp   2006-10-05 09:47:27.000000000 +1300
> @@ -1965,7 +1965,7 @@
>        * As the type of callback functions given to OpenGL, this type  
> must have
>        * C linkage.
>        */
> -    typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)();
> +    typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)(...);
>       /**
>        * @internal
> @@ -2033,7 +2033,8 @@
>                               reinterpret_cast<TessCB> 
> (tessExtrusionBegin));
>               gluTessCallback(&tesselator, GLU_TESS_VERTEX_DATA,
>                               reinterpret_cast<TessCB> 
> (tessExtrusionVertex));
> -            gluTessCallback(&tesselator, GLU_TESS_END, glEnd);
> +            gluTessCallback(&tesselator, GLU_TESS_END,
> +                                       reinterpret_cast<GLvoid (*) 
> (...)>(glEnd));
>               if (mask & viewer::mask_bottom) {
>                   TessExtrusion bottom(&c[0][0],
> 
> === PATCH ENDS ===

Lovely. This is presumably a bug in the Apple/Fink OpenGL
implementation. The GLU 1.3 spec (the latest I know of) specifies the
signature of gluTessCallback to be
        
        void gluTessCallback(GLUtesselator *tessobj, GLenum which, void (*fn );())
        
I don't know what's up with that semicolon there (probably just a typo);
but clearly the third argument isn't a varargs function.

I guess I will need to write a configure test to spot this. I will do
that before releasing 0.16.1. Can I send you a patch to configure.ac to
test?

BTW, I'd expect this to give lots of other people problems, too.

> Finally, one difficulty we are running into on the Intel-based Macs  
> is that the last official mozilla version does not compile on Intel  
> Mac OS X. Our options for the mozilla-1.8 and later branches are  
> firefox and seamonkey. Since the key thing mozilla is needed for on  
> the Mac openvrml builds is script node javascript, I would like to  
> add this back in at some stage. However, fiddling with autoconfig and  
> patching header files is not my idea of fun, so perhaps its something  
> you'd like to consider - the linux builds will eventually run into  
> the same issue, with users preferring firefox and/or seamonkey over  
> an aging mozilla.

Regrettably, mozilla.[org|com] has bungled things badly here. They
always did a pretty weak job of packaging development headers for
Mozilla; and with the Firefox and Seamonkey they seem to have dropped
the ball completely, pushing the responsibility for fishing the correct
headers out of the source tree onto packagers. Supposedly there will be
some Mozilla Runtime Environment distribution at some point in the
future that will solve all these problems and life will be peachy.
        
Meanwhile, it sucks.
        
I note that it appears that a firefox-devel package has replaced the
mozilla-devel package for Fedora Core 6. I can only hope that the new
package actually provides things that are required for building browser
plug-ins.

> So I am quite close to finishing the updated fink packaging.. if only  
> cc1plus wasn't so ram hungry when compiling vrml97node.cpp.. :-) I'd  
> be finished sooner.

gcc is a pig; its management of large symbols (which happen when you use
templates nontrivially) appears to suck rather badly. If you can build
without debugging symbols, things go significantly faster. FWIW.

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

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

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

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

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

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

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

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

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

Regards,
Phil.

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

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

On 04/10/2006, at 1:37 PM, Braden McDaniel wrote:

> On Wed, 2006-10-04 at 12:24 +1300, Philip Lamb wrote:
>> Firstly, I am building from the 0.16.0+cvs, under Mac OS X 10.4.8 on
>> an Intel MacBook Pro.
>
> I hope this means you checked out using the OpenVRML-0_16_0-RELEASE or
> the OpenVRML-0_16-BRANCH tag.
>

No, I was trying to be too clever, and compiling from head. I have  
reverted now to just the 0.16.0 release tarball, since it simplifies  
these issues, and is what fink users would get anyway.

> BTW, configure should be looking for Rez in the spot that you are
> specifying; thus it should not be necessary to set that environment
> variable. If it *is* necessary, I'd like to know about it.

I have let you know this before, but here is the output the autoconf  
"checking for Rez" step:

checking for Rez... /sw/bin:/sw/sbin:~/bin/i386-apple-darwin:/Users/ 
phil/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/ 
sbin:/usr/X11R6/bin:/Developer/Tools

i.e. it takes my whole path as the pathname of the rez executable.  
This fails during the build, since its not a valid path for Rez ;-)

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

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

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

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

This time, things went OK, except I did need to patch one file in  
order to keep gcc 4.0.1 happy.

=== PATCH BEGINS ===
diff -urN openvrml-0.16.0/src/libopenvrml-gl/openvrml/gl/viewer.cpp  
openvrml-0.16.0.patched/src/libopenvrml-gl/openvrml/gl/viewer.cpp
--- openvrml-0.16.0/src/libopenvrml-gl/openvrml/gl/viewer.cpp    
2006-02-25 21:39:42.000000000 +1300
+++ openvrml-0.16.0.patched/src/libopenvrml-gl/openvrml/gl/ 
viewer.cpp   2006-10-05 09:47:27.000000000 +1300
@@ -1965,7 +1965,7 @@
       * As the type of callback functions given to OpenGL, this type  
must have
       * C linkage.
       */
-    typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)();
+    typedef GLvoid (OPENVRML_GL_CALLBACK_* TessCB)(...);
      /**
       * @internal
@@ -2033,7 +2033,8 @@
                              reinterpret_cast<TessCB> 
(tessExtrusionBegin));
              gluTessCallback(&tesselator, GLU_TESS_VERTEX_DATA,
                              reinterpret_cast<TessCB> 
(tessExtrusionVertex));
-            gluTessCallback(&tesselator, GLU_TESS_END, glEnd);
+            gluTessCallback(&tesselator, GLU_TESS_END,
+                                       reinterpret_cast<GLvoid (*) 
(...)>(glEnd));
              if (mask & viewer::mask_bottom) {
                  TessExtrusion bottom(&c[0][0],

=== PATCH ENDS ===

Finally, one difficulty we are running into on the Intel-based Macs  
is that the last official mozilla version does not compile on Intel  
Mac OS X. Our options for the mozilla-1.8 and later branches are  
firefox and seamonkey. Since the key thing mozilla is needed for on  
the Mac openvrml builds is script node javascript, I would like to  
add this back in at some stage. However, fiddling with autoconfig and  
patching header files is not my idea of fun, so perhaps its something  
you'd like to consider - the linux builds will eventually run into  
the same issue, with users preferring firefox and/or seamonkey over  
an aging mozilla.

So I am quite close to finishing the updated fink packaging.. if only  
cc1plus wasn't so ram hungry when compiling vrml97node.cpp.. :-) I'd  
be finished sooner.

Cheers,
Phil.

[openvrml-develop] OpenVRML-0_16-BRANCH status

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

There have been some significant changes on the OpenVRML-0_16-BRANCH in
the last few days. These changes are mostly organizational.
Specifically, the openvrml-player backend used by the Mozilla plug-in in
the 0.16.0 release has been renamed to openvrml-gtkplug and moved to
src/openvrml-gtkplug in the package. This program is not dependent on
NPAPI in any way; and in fact it is suitable for general use by GTK+
applications. In the future I would like to write another front end for
it such that OpenVRML provides a stand-alone player in addition to the
Mozilla plug-in; but for now, the plug-in is the only front end
available.

I'll probably release 0.16.1 in the next week or so.

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

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

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

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

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

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

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

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

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

On Wed, 2006-10-04 at 12:24 +1300, Philip Lamb wrote:
> Hi all,
> 
> I thought it about time I updated my Mac OS X fink openvrml package  
> for the new release. However, I'm running into some fairly elementary  
> issues attempting to build it.
> 
> Firstly, I am building from the 0.16.0+cvs, under Mac OS X 10.4.8 on  
> an Intel MacBook Pro.

I hope this means you checked out using the OpenVRML-0_16_0-RELEASE or
the OpenVRML-0_16-BRANCH tag.

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

I don't quite understand what this means.

BTW, configure should be looking for Rez in the spot that you are
specifying; thus it should not be necessary to set that environment
variable. If it *is* necessary, I'd like to know about it.

>  If I remove offending bits, I can configure:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

which gets as far as looking for antlr:

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

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

cd lib/antlr
make

it bombs out with:

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

Can anyone illuminate?

Cheers,
Phil.

Re: [openvrml-develop] Status

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

On Sat, 2006-09-16 at 05:21 -0400, Braden McDaniel wrote:
> I've also been inching forward with getting Text node rendering working
> on Windows. While I still don't have a good understanding of the Right
> way to convert a CSS-style font specification into an actual font on
> Windows, I am at the point where I can pick *something*. So I expect to
> be at a point where I'll have something worth putting into a 0.16.x
> release before too long.

This is checked in and will appear in the forthcoming 0.16.1 release.
Remarkable how it all Just Worked once I finally figured out how to fish
out the file name associated with a font. (Windows makes this remarkably
difficult, AFAICT.)

FontStyle is currently ignored. It's going to take a bit more work to
nail down the mapping from FontStyle to a Windows "logical font". At
least now readable text displays.

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

[openvrml-develop] Status

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

The last release underscored for me once more what an annoying
dependency Antlr is for this project. So I've been scratching my Spirit
itch lately. I've finally figured out how to use Spirit's stored_rules
effectively to make a self-modifying grammar. That probably sounds a bit
more high-minded than it actually is; though it *is* pretty cool. Where
in Antlr I had used a semantic predicate to resolve ambiguity in the
grammar, the Spirit solution using stored_rules uses a semantic check to
swap out the branch of the grammar at parse time such that there's never
anything to disambiguate (at the grammar level).

Nothing's checked in yet; but this work is probably about 70% done. The
only construct I have left to parse is IS statements in PROTOs. And then
I'll need to go about making it construct OpenVRML scenes.

I'm planning on exposing this new parser such that users can use Just
The Parser directly, supplying their own semantic actions. This should
facilitate a more lightweight solution for users who just want to get
data out of a VRML file.

I have No Idea how this Spirit parser will perform relative to the
existing Antlr one; but it will be interesting to see.

I've also been inching forward with getting Text node rendering working
on Windows. While I still don't have a good understanding of the Right
way to convert a CSS-style font specification into an actual font on
Windows, I am at the point where I can pick *something*. So I expect to
be at a point where I'll have something worth putting into a 0.16.x
release before too long.

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

Re: [openvrml-develop] ANN: OpenVRML 0.16.0

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

Josip Almasi wrote:
> Braden McDaniel wrote:
> 
>> OpenVRML 0.16.0 is now available.  The distribution can be obtained
>> from
> 
> Good news:)
> 
> But I can't compile it...
> 
> openvrml/browser.cpp:43:44: boost/ptr_container/ptr_map.hpp: No such 
> file or directory
> 
> and loads of subsequent errors.
> I do have boost, 1.32 on red hat 4, there's no that ptr_container 
> directory...?

Sorry, Boost 1.33.1 is required. README ought to mention that, but it 
doesn't. I'll update it for the next release.

Braden

Re: [openvrml-develop] ANN: OpenVRML 0.16.0

[Josip A. <jo...@vr...>]

Braden McDaniel wrote:

> OpenVRML 0.16.0 is now available.  The distribution can be obtained
> from

Good news:)

But I can't compile it...

openvrml/browser.cpp:43:44: boost/ptr_container/ptr_map.hpp: No such 
file or directory

and loads of subsequent errors.
I do have boost, 1.32 on red hat 4, there's no that ptr_container 
directory...?

Regards...

Re: [openvrml-develop] C# and Tao

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

On Mon, 2006-08-21 at 12:20 +0100, Euan Woolley wrote:
> Hello,
> 
> Is there any scope for paying someone to do this job?

Solicitation for paid OpenVRML-related work is welcome here and on
openvrml-announce.

>   If not, does
> anyone know of a website where you can offer money for small contracts?
> I'm sure I saw one once but now I can't find it.

Perhaps you're thinking of rentacoder.com? (There are other such sites
as well, but that one comes to mind.)

>   I would be happy for
> the resulting work to be owned by the Open VRML project,

While I appreciate the offer, I don't think including a C# binding in
the OpenVRML distribution is particularly pragmatic. I lack the
knowledge and resources to maintain such a thing; and focusing on
providing the C++ libraries means that n bindings don't have to be
updated before I can make a release.

This, of course, should not hinder you from releasing your binding as
its own free software package, should you pursue this.

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

Re: [openvrml-develop] C# and Tao

[Euan W. <Eu...@sm...>]

Hello,

Is there any scope for paying someone to do this job?  If not, does
anyone know of a website where you can offer money for small contracts?
I'm sure I saw one once but now I can't find it.  I would be happy for
the resulting work to be owned by the Open VRML project,

Euan

Euan Woolley wrote:
> Hello,
>=20
> =20
>=20
> Does anyone have any tips on how I can use Open VRML with the Tao
OpenGL
> wrapper in C#?  I'd like to be able to import VRML geometry into my
> application.  I don't have any interest in any of the stuff in a VRML
> file apart from the geometry (no lights or anything).
>=20
> =20
>=20
> What I'd like to be able to do is:
>=20
> =20
>=20
> VRMLObject obj =3D new VRMLObject(@"a file.wrl");
>=20
> Gl.GlNewlist(aList);
>=20
> Obj.LoadGeometryToGL();
>=20
> Gl.GlEndList();
>=20
> =20
>=20
> =20
>=20
> Or similar.
>=20
> =20
>=20
> Will it be possible?

I'm not familiar with C# or Managed C++, so I cannot help you with=20
getting from C++ to C#. Though from what little I understand, it is=20
possible.

But on the OpenVRML side of the fence, the typical way to pick stuff out

of the VRML scene graph is to use openvrml::node_traverser. Also have a=20
look at the openvrml::browser documentation; in particular=20
openvrml::browser::do_get_resource.

After deciding that SourceForge isn't going to fix their CVS problems on

shell.sf.net any time soon, it finally hit me that I could use rsync to=20
update the Web site easily enough. So the 0.16.0 documentation has now=20
been uploaded. The main page now sports an initial feeble attempt at=20
"user guide" style information. Feedback regarding what is missing can=20
help me better direct my energies in improving it.

Braden

------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
openvrml-develop mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] OpenVRML 0.16.0 vs. Microsoft cl 14.0

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

On Fri, 2006-08-18 at 17:53 -0700, Greg Roelofs wrote:
> > What I'm seeing appears to be rather severe memory corruption. (Well, as
> > if that's ever mild.) The code as it is in CVS doesn't even make it
> > through static initialization before keeling over. I was able to get
> > past that with a couple of tweaks (specifically, converting
> > component_registry and profile_registry to singletons); but that just
> > led to more bizarre problems.
> 
> Is it possible the default C library changed and you're still linking
> against other libraries that were compiled the old way?

The project files included in the OpenVRML distribution don't link with
any libraries outside the source distribution (that aren't included with
the compiler/Platform SDK). So, no... I don't think this is the issue.

Per the other message I just posted, the static initialization problems
are only showing up when OpenVRML is built as static libraries. Very
strange.

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

Re: [openvrml-develop] OpenVRML 0.16.0 vs. Microsoft cl 14.0

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

On Fri, 2006-08-18 at 00:50 -0400, Braden McDaniel wrote:
> I've spent a few frustrating hours trying to get OpenVRML compiled with
> Microsoft cl 14.0 (the one that comes with Visual Studio 2005) to work.
> And I'm just about to give up.

[snip]

Some good news: with the fixes I checked in today, the DLL build of
OpenVRML appears to work. (I have successfully loaded rotation_toy.wrl
with sdl-viewer, at least.)

The problems I was observing seem to appear only when openvrml and
openvrml-gl are built as static libraries. So far, I don't have any
particular insight into those problems, though.

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