|
From: Braden M. <br...@en...> - 2010-03-15 20:12:13
|
On Mon, 2010-03-15 at 10:20 -0700, Greg Roelofs wrote: > >> - D-Bus does _not_ automatically start openvrml-xembed on my box. No clue > >> how that's supposed to work. The workaround mentioned on the list works, > >> but the README is slightly misleading. > > > You do have to install it for this to work. > > Sorry, I meant to note that this was after I installed it (openvrml) via > "make install" as root. Or did you mean D-Bus itself? Presumably D-Bus is already installed on a reasonably modern Linux. > > It works (when it does) > > because OpenVRML installs a descriptor to a place that D-Bus knows > > about. On Fedora, that's: > > > /usr/share/dbus-1/services/org.openvrml.BrowserControl.service > > > If D-Bus is looking somewhere different on Debian, that would be a > > problem. > > I have that directory, but there's no openvrml file in there. Very strange. > I do see the relevant test and install command in my log, but it didn't work: > > [...] > ---------------------------------------------------------------------- > test -z "/usr/local/include/openvrml" || /bin/mkdir -p "/usr/local/include/openvrml" > /usr/X11R6/bin/install -c -m 644 libopenvrml/openvrml-config.h libopenvrml/openvrml-common.h libopenvrml-gl/openvrml-gl-config.h libopenvrml-gl/openvrml-gl-common.h '/usr/local/include/openvrml' > test -z "/usr/local/share/dbus-1/services" || /bin/mkdir -p "/usr/local/share/dbus-1/services" > /usr/X11R6/bin/install -c -m 644 openvrml-xembed/org.openvrml.BrowserControl.service '/usr/local/share/dbus-1/services' > make[4]: Leaving directory `/util/3D/openvrml-0.18.5/src' > make[3]: Leaving directory `/util/3D/openvrml-0.18.5/src' > make[2]: Leaving directory `/util/3D/openvrml-0.18.5/src' > make[1]: Leaving directory `/util/3D/openvrml-0.18.5/src' > Making install in data > [...] > > Not installed and later removed, either: > > % ll -d /usr/share/dbus-1/services > drwxr-xr-x 2 root 4096 Aug 1 2009 /usr/share/dbus-1/services/ > > Weird. You're installing OpenVRML under /usr/local while you have D-Bus installed under /usr. So, openvrml-xembed's service descriptor is going to wind up in /usr/local/share/dbus-1/services. > > Are the other problem worlds publicly available? > > I've just uploaded a tarball here: > > http://gregroelofs.com/test/grr-openvrml-0.18.5-test.tgz Thanks. I'll check these out. > > sdl-viewer doesn't use openvrml-xembed. The idea behind openvrml-xembed > > is to have a single viewer backend that is usable as either a > > stand-alone viewer or a browser plug-in. > > Huh...I completely missed that. OK, that explains it. sdl-viewer also only knows how to load local files. libopenvrml is network-agnostic; and this extends to openvrml-xembed. openvrml-xembed actually relies on its container to provide resource fetching services. openvrml-player uses libcurl for that part, while the Web browser plug-in uses NPAPI services. > > Fixable. :-) But if you plan on using this to build software, I'd > > recommending 4 GB of RAM if you want to use x86_64 Linux. gcc can > > consume a lot of memory; and IME, x86_64 can really nearly double its > > memory consumption. > > Good to know, thanks. If the box is capable of it, I may go straight to 8. The 330 is a quirky little beast. Even though it supports x86_64, it can only see 4 GB of memory. (Well, really more like 3.5.) -- Braden McDaniel <br...@en...> |