|
HowToBuild
How to get the source and build.
PrerequisitesAll platforms
Windows
Additional (free) downloads
Mac OS X
Linux
If you are using a Debian-based distro and you want to build the .deb package, you will also need these packages:
Checking out the codeThe gclient config step only needs to be run once to set up your working directory. It creates a .gclient file in your working directory that identifies the corresponding structure to pull from the repository. The gclient sync step creates several subdirectories. To update your tree in the future, you only need to run gclient sync from anywhere within your working directory.
Important: Make sure the full directory path has no spaces. cd $O3D_ROOT gclient config http://src.chromium.org/svn/trunk/src/o3d
cd $O3D_ROOT gclient sync
Building
Just like Chrome, O3D Uses GYP to generate build files for each of the platforms. On Windows, this produces .sln and .vcproj files, on Mac OS X it produces .xcodeproj bundles, and on Linux it produces SConscript files. Building on any supported platformIf you just want to build regardless of platform you can use gypbuild to do the building for you. From the $O3D_ROOT/o3d folder type ./gypbuild on any platform. For more info about gypbuild try 'gypbuild --help'. Otherwise for specific platforms see below. Building on WindowsOn Windows, GYP produces the solution files that are to be loaded into Microsoft Visual Studio. The "main" solution file is called "o3d.sln", and will appear in the $O3D_ROOT\o3d\build directory. Load this file into Visual Studio, and build it as you would any other Visual Studio file. The output will appear in the $O3D_ROOT\o3d\build\Debug or $O3D_ROOT\o3d\build\Release directory, depending on the build you do. Building different renderersO3D has two different renderers on Windows, a D3D-based renderer, and an OpenGL-based renderer. The D3D renderer is the default, but if you want to build the OpenGL renderer, set the variable "GYP_DEFINES" to "renderer=gl" and run the command gclient runhooks --force to regenerate the solution/vcproj files. Unfortunately switching between renderers requires a rebuild, as they use the same output directories currently. Building on MacOn Mac OS X, GYP produces the XCode build files that are to be loaded into XCode. The "main" build file is located in $O3D_ROOT/o3d/build/o3d.xcodeproj. Load this file into XCode, and build it as you would any other XCode file. The output will appear in the $O3D_ROOT/xcodebuild/Debug or $O3D_ROOT/xcodebuild/Release directory, depending on the build you do. Building on LinuxOn Linux, GYP produces SConscript and .scons files. The main SConscript is in $O3D_ROOT/o3d/build/o3d_main.scons. To build this file, use 'hammer' from the software construction toolkit (installed as part of the depot_tools). Change directories into the $O3D_ROOT/o3d/build directory, and type hammer -f o3d_main.scons Note: to build the 64-bit plugin, you need to tell gyp that you are building it, by setting the GYP_DEFINES environment variable to target_arch=x64 before you run gclient sync (or run gclient runhooks --force). At the moment, Linux requires special instructions to run, see below.
hammer -s -j3 -f o3d_main.scons # build quietly running 3 compiles at a time hammer --verbose -f o3d_main.scons # display full command lines (useful for debugging compile and links errors) hammer -C $O3D_ROOT/o3d/build -f o3d_main.scons # build from where you are You can also use make instead to build, using similar instructions to Chromium's: # Update and rebuild makefiles if needed export GYP_GENERATORS="make" gclient sync # Build everything. make -C $O3D_ROOT O3D_All # Only build the plugin. make -C $O3D_ROOT npo3dautoplugin Note: the output of the make build goes to $O3D_ROOT/out instead of $O3D_ROOT/sconsbuild. Running/Debugging on LinuxOn Ubuntu and other Debian-derived systems, the build process will produce a .deb installer package in the output directory (provided dpkg-buildpackage is installed—see above). To install, simply execute sudo gdebi-gtk <file> with the appropriate .deb file (...i386.deb for 32-bit systems, or ...amd64.deb for 64-bit systems). For non-Debian-derived systems, you currently must install O3D manually. scons builds the plug-in—a shared library named libnpo3dautoplugin.so—into the output directory. This needs to be findable by your web browser, and you have several options for that:
Additionally, that plug-in dynamically links with other shared libraries that your browser needs to find: libGLEW.so.1.5, libCg.so and libCgGL.so. libGLEW.so.1.5 is a standard open-source package and should be available in your distribution's package manager repositories (if not, there is a copy checked-in to O3D's source tree which you can put into /opt/google/o3d/lib). libCg.so and libCgGL.so must be installed manually. You have several options:
After you have installed, launch your browser and try our samples (in googleclient/o3d/samples). Running testsUnit testsYou can run unit tests and other tests using scons. scons unit_tests # runs unit tests SeleniumThe Selenium tests form a suite of automated browser integration tests. Several pages are loaded into the browser and actions performed on them to ensure that they function as expected. The customized selenium script for O3D takes screenshots of the display buffer and uses perceptualdiff to compare them with reference screenshots. Note: Screenshots are only taken and diffed in the test-* builds. (eg. Use MODE=test-dbg-d3d to build the test build of the dbg-d3d) To run selenium tests, execute: scons selenium MODE=test-dbg-d3d (Replace test-dbg-d3d with whichever build you want to test.) There are several other flags pertaining to selenium that you can use: (eg.) scons selenium MODE=test-dbg-d3d SELENIUM_VERBOSE=0 SELENIUM_BROWSERS=*firefox # Test the test-dbg-d3d build on firefox with no verbose output SELENIUM_VERBOSE = {0, 1} Controls if verbose output is displayed for debugging purposes. SELENIUM_BROWSERS = Comma-delimited string of browsers to test in selenium. Currently supported browsers for testing in selenium:
You can choose individual tests like this scons selenium SELENIUM_TEST_PREFIX=TestSampleRotateModel Which will effectively test only TestSampleRotateModel. The argument is a prefix so TestSampleW will run any test that starts with TestSampleW. |
► Sign in to add a comment
I'm so sick of these backwards 32-bit development efforts! Seriously, people, just stop supporting 32-bit entirely! Force those who have been dragging their feet for the last 10 YEARS to finally upgrade!
I'm so sick of these backwards 1280x1024 development efforts! Seriously, people, just stop supporting 1280x1024 screens entirely! Force those who have been dragging their feet for the last 10 YEARS to finally upgrade!
I'm so sick of these backwards IE development efforts! Seriously, people, just stop supporting Internet Explorer entirely! Force those who have been dragging their feet for the last 10 YEARS to finally upgrade!
Brand new netbooks aren't 64-bit.
I'd really like 64 bit support as well on gears and o3d.
I'm so sick of these backwards Nike shoes development efforts! Seriously, people, just stop supporting Nike shoes entirely! Force those who have been dragging their feet for the last 10 YEARS to finally upgrade!
its so difficult to install it could you please provide a deb,rpm installation or sh or a Firefox add-on
请问，有没有比较简单的安装方法？
I'm waiting for 64bit...
me too
yup, me too.
Please stop 32bits support, or at least, put that effort in second place. also support konqueror as well, it's almost the same as supporting safari....... finaly, please be aware that packaing exists under linux distributions. old school build, tar and the like are for 80's. don't work in the past please!
I'm so sick of these backwards old school build efforts! Seriously, people, just stop supporting 80's culture entirely! Force those who have been dragging their feet for the last 20 YEARS to finally upgrade!
So far I fail on the "gclient sync" step. Anyone else gets some errors like that?
Traceback (most recent call last):
IOError: 2? No such file or directory: 'containing'Despite being very interesting this is not the first 32-bit only plugin made by Google. They should start paying attention to the 64-bit folks or they're going to lose all the developers on 64 bit platforms to other companies.
And yes, they start looking as if they can't keep up with modern technology. Is this the meaning of backward?
did anyone succeed to compile it on x64 linux?
As for me I would prefer a precompiled version for installation, or even better a firefox plugin.
zeilfelder, did you try adding depot_tools to your path? That might help. Also be sure you are using the most up to date version of depot_tools (there is a link here: http://dev.chromium.org/developers/how-tos/install-gclient). Fresh install on a 32-bit machine seems to working so far for me.
necro351 - I installed depot_tools from svn today, so it should be newest version (hm, maybe too new...). I also tried already adding it to the path, that's not it. And it's a 32-bit machine running debian lenny, so I guess that should also be fine. Well, I was just curious anyway.
Any idea what is going wrong here?
Linking scons-out/opt-linux/obj/converter/o3dConverter scons-out/opt-linux/lib/libFColladaU.a(FArchiveXML.o): In function `FArchiveXML::ExportDocument?(FCDocument, xmlNode)': FArchiveXML.cpp:(.text+0x5feb): undefined reference to `FCDLibrary<FCDPhysicsModel>::GetAsset?(bool)'
hear hear. Collada doesn't want to build. OS: Ubuntu, 8.10
Python 2.4.5 gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2 g++-multilib - 4.3.2 libxt-dev 1.0.5
cons-out/opt-linux/lib/libFColladaU.a(FArchiveXML.o): In function `FArchiveXML::ExportDocument?(FCDocument, xmlNode)':
Same here : scons-out/opt-linux/lib/libFColladaU.a(FArchiveXML.o): In function `FArchiveXML::ExportDocument?(FCDocument, xmlNode)': FArchiveXML.cpp:(.text+0x38eb): undefined reference to `FCDLibrary<FCDPhysicsModel>::GetAsset?(bool)' FArchiveXML.cpp:(.text+0x3991): undefined reference to `FCDLibrary<FCDPhysicsScene>::GetAsset?(bool)' (...)
OS:Ubuntu 8.10 /usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
In linux you also need libglu1-mesa-dev
it would be nice to have a deb for amd64 (64bit support is really appreciated)
Yes, libglu1-mesa-dev solved a previous compile error. Collada is more annoying.
32Bit is still major part of personal computing architectures, so don't be stupid by requering a stop on 32-bit builds. Just ask for a 64bit support if you need it. Don't act like fools. It's annoying.
OK, I found out how to fix the error I got. Probably I have made some error in the "gclient config" command. After deleting the .gclient file and running config again I could download the sources.
Instead of opt-linux, I created dbg-linux, which of course will run much slower. But that one builds successfully. So probably the SConscript will strip some symbols on opt-linux that are needed.
Furthermore: if you are running a 64 bit browser (e.g. 64 bit Iceweasel) you will have to use nspluginwrapper (and of course have a multilib install with support for 32 bit ELF in the Linux kernel) to get things working. That means you have to ignore the section ''Running/Debugging on Linux'', but instead follow roughly the following steps:
Make libCgGL.so, libCg.so and libGLEW.so.1.5 available as loadable 32 bit shared libraries. Maybe you need to create a symlink libGLEW.so -> libGLEW.so.1.5 (if you plan to copy those libs to /usr/lib32, running ldconfig afterwards should suffice)
run the command: nspluginwrapper -i $O3D_ROOT/googleclient/o3d/scons-out/dbg-linux/artifacts/libnpo3dautoplugin.so
Now about:plugins (if your browser supports it) should list nspluginwrapper AND O3D Plugin (for me nspluginwrapper was the first entry in the list, and O3D Plugin was the last one). If O3D Plugin is not listed, run your browser from command line and look out for error messages.
However, for me it does not work:
:We are terribly sorry but it appears your graphics card is not able to run o3d. We are working on a solution.
and stderr says: 0423/131131:ERROR:core/cross/gl/renderer_gl.cc(675)? GL drivers do not have OpenGL 2.0 functionality. 0423/131131:ERROR:core/cross/gl/renderer_gl.cc(690)? GL drivers do not support framebuffer objects.
Which brings me back to intel drivers and the question when it will support OpenGL 2.0. Concerning the fbo thing, I was pretty sure it was supported. Anyway, I do not have time to look into this.
guys - great idea, fantastic that you've created it - really good. unfortunately: absolutely shit execution of the build process.
1) i'm watching the svn checkout and i'm seeing 1.2 GIGABYTES of crap, so far, including binary-distributions of cgc (including win32 dlls, linux 32-bit .so's, linux 64-bit .so's and macosx binaries). i'm seeing an ENTIRE copy of libicu38, a copy of doxygen??? are you on drugs or something?? fcollada has been sucked in, in its entirety, including pre-built documentation.
2) scons?? come on, folks - there's a good reason why autoconf was created. i realise that scons has noddy win32 support, but every major free software project copes with that lack by e.g. using mingw32 cross-compiling (where you can still use autoconf) or by creating a separate build process (if you force people to use the proprietary MSVC compiler, you and they get what they deserve).
3) autoconf and configure allows you to specify dependencies in a clean, portable manner. pkgconfig manages the build dependencies via .pc files in a clean, portable manner.
just because you work for google doesn't mean you can blatantly ignore the experience of large free software projects, especially if you expect anyone from the free software community to get involved and help out.
i'm really sorry to have to be telling you these things, because browsers really do need 3D capability, badly, as it's browsers that are becoming the "standard" that is replacing "desktop apps".
so it's absolutely, absolutely brilliant that o3d exists.
it just needs to not be packaged in such a way as to blatantly disregard the hard-earned experience of free software development. i.e. - whoever told you that using scons is a good idea, take them out the back, beat them up, dig a pit and throw them in it.
if you think, "who the hell is this guy to tell us this???" then take a look around you: do you see any prominent free software project that uses scons? what does webkit use? autoconf. what does apache use? autoconf. what does samba use? autoconf. what does python use? autoconf. what does firefox use? autoconf. what does icu use? well, it's maintained by IBM, so it uses hand-crafted Makefiles, the silly buggers.
what does that tell you? (apart from libicu, that is...)
it would be nice to have a deb for amd64 (2)
Apart from that, O3D is amazing.
Yeah, i'm waiting 64-bit supp too.
Whenever I run scons, I get a whole bunch of deprecation warnings, and then this:
In file included from ./core/cross/precompile.h:52,
/home/home/.o3d/googleclient/third_party/glew/files/include/GL/glew.h:1138:20: error: GL/glu.h: No such file or directory scons: scons-out/opt-linux/obj/core/cross/bounding_box.o? Error 1Has anyone gotten this error and solved it?
I can confirm that compiling with MODE=dbg-linux will get rid of the unresolved collada externals.
@ andrei.shindyapin: you miss some opengl development headers. libglu1-mesa-dev has those probably.
Please, stop ranting about 32 bit vs. 64 bit or about packaging.
the 32 bit thing: O3D is currently 32 bit only. That means there is a 32 bit version for x86, but no other version like native amd64. This does not mean that you can not use it on an amd64 compatible processor with a native amd64 system. The reason why amd64 has been successful is that it is backward compatible with x86. So, if your 64 bit system has not removed support for 32 bit programs (which is very unlikely), you will be able to use 32 bit programs. There are only few and rarely seen exceptions. An x86 version will usually be executed slightly slower than an amd64 version, but also have a slightly smaller size. O3D currently seems to be some sort of beta stage. It currently even only supports some part of the available graphics cards. If O3D has a positive future, I am pretty sure, there will be some native am64 version. When time has come, It will probably also build on ARM, SPARC and other architectures. And it will run on FreeBSD, OpenSolaris? etc. The choice to first support x86 is pretty obvious, because it runs on x86 and on amd64. If you drop support for x86 and instead support amd64 only, you won't be able to run it on x86 only processors, which are still being produced and widely in use (like Intel's Atom).
the packaging thing: Yes, Google could build some debs or rpms. But I personally would not like to see that. It is the task of the distributions or community members of the distributions to create packages like deb or rpm, because they can test it, fix minor things, set up the right dependencies etc. If Google created packages, people would start complaining about distribution x being preferred over distribution y, about not working packages and with the demand to fix it. But this is something Google can not handle. You can not except Google to test hundreds of installs on different systems. It is up to the community to make this packaging, testing and adapting things.
The thing about those 1.5 GB of download. Well… yikes! It took me quite a while to fetch all that. But I think it could be worse. I just hope the Google devs did not make serious changes to the external libraries they are using. If it is easy to replace them with the distribution packages, then I think it is ok. It is their way of doing this. Maybe it causes a lot of traffic, but it works. This is more important. (btw: If they did not include all those libraries and programs, there would be far more dependencies.)
hiya walch,
the thing about using gnu autoconf is that you can specify the exact / minimum / maximum version of a particular library, and you can even specify the exact / minimum / maximum version of a particular application, such as flex, bison etc. in the extremely unlikely event that an M4 macro does not exist to allow you to specify which version you want, there are so many examples to choose from to blatantly cut/paste it's unreal.
my guess is that distro maintainers are going to take one look at this dog's dinner approach and go "absolutely no way we're touching this".
> If Google created packages, people would start complaining about > distribution x being preferred over distribution y, > about not working packages and with the demand to fix it.
that's why you simply create a debian/ subdirectory and leave it at that, and do not produce actual .deb binary packages.
make the debian maintainers lives easier by spoon-feeding them or anyone else with a pre-prepared debian/ directory that any script kiddie can download and run "dpkg-buildpackage" on.
if someone wants a looovely .deb for their looovely screwed-up system such as ubuntu, they get told "run apt-get build-essential, .... run dpkg-buildpackage and please go away".
and guess what debian/control file specifies (in combination with the buildpackage process itself) ? all the specific and exact package and build dependencies, version numbers and all.
> When time has come, It will probably also build on ARM, SPARC and other > architectures. And it will run on FreeBSD, OpenSolaris??
you would get that "for free" - with no additional effort - if the o3d team bothered to use autoconf.
as it is they have just created themselves a total nightmare, thanks to some twit saying "yes! python and scons are cool!". and i'm a pathological python-favourer, but even i can see that scons is a dead-end and a wildly inappropriate tool for this job.
that having been said, v8 is only available for 32-bit ARM and 32-bit x86 (and uses scons) so any other platforms are moot right now. that's not an excuse to not use the right tool - just because the v8 team stuck their head in the oven doesn't mean the o3d team has to do the same.
In file included from /Google/O3D/googleclient/third_party/chrome/files/base/string_util.h:15,
/Google/O3D/googleclient/third_party/chrome/files/base/string16.h: In static member function 'static int base::string16_char_traits::eof()': /Google/O3D/googleclient/third_party/chrome/files/base/string16.h:119: error: 'EOF' was not declared in this scope scons: scons-out/opt-linux/obj/utils/cross/json_writer.o? Error 1 scons: building terminated because of errors.We are terribly sorry but it appears your graphics card is not able to run o3d. We are working on a solution.
0426/124439:ERROR:core/cross/gl/renderer_gl.cc(675)? GL drivers do not have OpenGL 2.0 functionality. 0426/124439:ERROR:core/cross/gl/renderer_gl.cc(690)? GL drivers do not support framebuffer objects.
Does it means I'll have to revert to proprietary ATI drivers ?
I would like 64 bit support.
I wouldn't mind running a 32 bit browser in the mean time but I have been unable to compile it for 32 binary nor have I been able to find one that someone else compiled. Would google consider providing pre-built linux binaries (even if it is just for 32 bit)?
32-bit only? Give me a break!
SIXTY FOUR (64) BIT, PEOPLE
Am I gonna have to learn Javascript now? Oh balls. Can someone clever explain to me whether it's likely there will be other language bindings for this in the future? Thanks!
Hello luke.leighton,
maybe you are right that scons is not the right tool. But autotools have IMO also some negative aspects. I think it is more difficult to maintain. Environment variables of a running shell may have an impact on configure scripts. Code that is generated by autotools is really hard to read. (There are no functions. I think configure scripts are even not Turing complete. This results in huge, ugly and slow code.) Anyway, it is not up to me to select the toolchain.
I started looking for the linker problem. I could not figure out why exactly the symbols are removed. But when compiling those libraries with -O1 instead of -O2, it works fine.
Same problem for me. I have a ATI Mobility Radeon X600 (rv380) on Ubuntu 9.10 Karmic (testing) and Mesa drivers with OpenGL 1.4 support
googleclient/third_party/chrome/files/base/string16.h: In static member function 'static int base::string16_char_traits::eof()': googleclient/third_party/chrome/files/base/string16.h:119: error: 'EOF' was not declared in this scope scons: scons-out/opt-linux/obj/utils/cross/json_writer.o? Error 1 scons: building terminated because of errors.
I want amd64 version and precompiled.
wanfang liu.. 没有 :)
bump request for 64-bit support
anyone have a pre-compiled package for linux? for every update i got a diferent error ..
When I run ./scons on my linux the following error message is emitted:
scons: Building targets ... scons: `sample' is up to date. scons: done building targets. java -cp /mnt/windows/o3D/googleclient/o3d/../third_party/antlr3/lib/antlr-3.1.1.jar org.antlr.Tool compiler/technique/Technique.g3pl -fo scons-out/dbg-linux/obj/compiler/technique sh: java: command not found scons: scons-out/dbg-linux/obj/compiler/technique/TechniqueLexer?.c? Error 127 scons: building terminated because of errors. normal@DEVARDE-PC:/mnt/windows/o3D/googleclient/o3d$
However despite of that message says I have the java on my PATH. My PATH is:
normal@DEVARDE-PC:~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/java/bin:/usr/lib/java/jre/bin:/usr/lib/qt/bin:/usr/share/texmf/bin:.:/home/normal/jdk1.6.0_10/fastdebug//bin
Why happen that? What do you suggest for me?
My OS is Slackware Linux 12.2 32 bits with kernel hugesmp.s (2.6.27.7-smp)
Thanks for all, I am looking forward any suggestions.
I'm so sick of these backwards compatible development efforts! Seriously, people, just stop supporting previous version entirely! Force those who have been dragging their feet for the last 10 MINUTES to finally upgrade!
did some one manage to compile on Ubuntu 9.04 I get tons of undefined references. for example: FAXSceneExport.cpp:(.text+0x60c): undefined reference to `FUStringBuilderT<char>::~FUStringBuilderT()' googling FUStringBuilderT harvests to few results I could not feature out what missing. Any idea ?
I'm so sick of upgrading to new devices that work like st! Stop manufacturing crap, like iPods, Cellphones, DVR's, Dishwashers, Washing Machines.
I spent 2 evenings at installing it on my Linux: I was very happy that a big 3D plugin was designed also for Linux, for once...
So, when I got the "We are terribly sorry but it appears your graphics card is not able to run o3d. We are working on a solution." error message, I was terribly sorry as well T_T Anyway, I'll have to wait for another release... Just hope it won't take years to support ATI...
Just a note: instructions for build are quite clear, so long as it is intended for computer scientists. Just an opinion: It would be great if you could add 3 separated sections: Build for Windows, Build for Mac, and Build for Linux. Although you would repeat information, it would be more straighforward for readers. Besides, the last section about "Running/Debugging on Linux" may not be understood by newbies to Linux.
Anyway, thanks for supporting Linux and good luck for development of O3D!
Would anyone be kind enough to upload a Linux binary? I've never been able to get this to compile...
you're not alone--try compiling it in debug mode, though...that works for me (now if only i could get it to load...)
For those who have error with "error: 'EOF' was not declared in this scope", open file named third_party/chrome/files/base/string16.h and add:
after the first #include you see (on top of file)
I will send patch to compile on Linux
Regards
I tried building with ./scons MODE=opt-linux and got:
Linking scons-out/opt-linux/obj/plugin/libnpo3dautoplugin.so /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../libgtk-x11-2.0.so when searching for -lgtk-x11-2.0 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../libgtk-x11-2.0.a when searching for -lgtk-x11-2.0 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libgtk-x11-2.0.so when searching for -lgtk-x11-2.0 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libgtk-x11-2.0.a when searching for -lgtk-x11-2.0 /usr/bin/ld: skipping incompatible /usr/lib/libgtk-x11-2.0.so when searching for -lgtk-x11-2.0 /usr/bin/ld: skipping incompatible /usr/lib/libgtk-x11-2.0.a when searching for -lgtk-x11-2.0 /usr/bin/ld: cannot find -lgtk-x11-2.0 collect2: ld returned 1 exit status scons: scons-out/opt-linux/obj/plugin/libnpo3dautoplugin.so? Error 1 scons: building terminated because of errors.
Anyone know what package -lgtk-x11-2.0 is in, or what it is looking for?
i had a problem with compiler/technique/Technique.g3pl and managed to get it working under debian by switching to sun's java-6 instead of gij. This is done with "update-alternatives" under debian.
scons: scons-out/dbg-linux/artifacts/google-o3d_0.1.39.0-1_amd64.deb? Error 3 scons: building terminated because of errors.
Getting that error.. I don't even have an AMD64 proc, i'm using a Dell XPS1530 w/ ubuntu 9.04, nvidia 8400m, 2gb ram, core2duo 2.2ghz D:?
Any ideas of how to fix this, I tried searching but to no avail.
Sorry I cannot solve this issue:
java -cp /home/sylar/o3d/o3d/third_party/antlr3/lib/antlr-3.1.1.jar org.antlr.Tool compiler/technique/Technique.g3pl -fo scons-out/opt-linux/obj/compiler/technique sh: java: command not found scons: scons-out/opt-linux/obj/compiler/technique/TechniqueLexer.c? Error 127 scons: building terminated because of errors.
I have java installed & running (the path is correct and averything works)
I'm on Arch 32 with the 2.6.29 kernel
HAHAHA 32bit plugin only, omg... is that a joke !?! or is this for real ?! What kind of computers they use? 64bit cpu are in use since years. The old PCs i386 with voodoo accelerators connected to graphic card with loop-back!?!
That's pitiful
I finally succedeed to build the plugin on linux for my HATED radeon 3200. I had problems with the shaders ("error C6002: Instruction limit of 0 exceeded") and commented out the cgGLSetOptimalOptions() call to functions on line 728 and 732 of the file o3d/core/cross/gl/renderer_gl.cc The plugin is fracking awesome :DD thanks google!!
都是英文的看不懂啊 能不能写点中文的
I'm so sick of these backwards condom development efforts! Seriously, people, just stop having sex entirely! Force those who have been dragging their feet for the last 10 YEARS to finally upgrade! I love google.
when google will release the sex application ?
"Google Sex has come out ! Just click "have sex" to find an address of a potential partner that is open or fit for open source sex ! Also, all locations of you nearest condom distributor! Don't hold that nasty envy for much longer ! Certified healthy! Don't forget to check the partner check age before inserting anything."
kdlucas: see the comment about symlinks in the Linux section above. What worked for me (on a 64-bit hardy install):
(I initially manually ln -s'd libgtk-x11 and libgdk-x11 and then got whined at about atk-1.0 and just the did the for loop above).
For completeness, I also had to:
I'm so sick of these old comments! Seriously, people, just stop reading comments older than this one entirely!
(Seriously, though, 64-bit packages would be nice rather than pulling in the entire build environment just to have a look ...)
I quote the comment by ami.fischman, on ubuntu the build do not work (error: "debchange not found") without the package devscripts, needed to make the deb package I initially changed the file o3d/installer/linux/build.scons to prevent the creation of the package in order to finish the build, but the problem is solved installing the devscripts package.
Guys, I'm a newbie here & I'm building the o3d plugin to learn the technologies used. I encountered a linking error(error stack attached) related to machine configuration. My system is a windows 64 bit and It seems I'm using 32 bit libraries to build a 32 bit plugin. Please tell me is it possible to build a 32 bit plugin on my machine & if possible are there options in the configuration file? Thanks in advance
Linker error trace Warning: Unable to load win32file module; using copy instead of hard linking for env.Install(). Is pywin32 present? scons: done reading SConscript files. scons: Building targets ... Creating library scons-out\opt-d3d\obj\plugin\o3dPlugin_logging.lib scons-out\opt-d3d\obj\plugin\win\plugin_metrics-win32.obj : fatal error LNK1112: module machine type 'x64' conflicts wit h target machine type 'X86' scons: scons-out\opt-d3d\obj\plugin\o3dPlugin_logging.lib? Error 1112 scons: building terminated because of errors.
This thing is neat and representative of what can be done, but gods I hope this isn't made the standard for 3D online. It just lacks so much still.
Is the Linux build currently broken? I tried to build it and got: Compiling scons-out/dbg-linux/obj/base/string_util_icu.o third_party/chrome/files/base/string_util_icu.cc:13:28: error: unicode/numfmt.h: No such file or directory third_party/chrome/files/base/string_util_icu.cc:14:26: error: unicode/ucnv.h: No such file or directory third_party/chrome/files/base/string_util_icu.cc:15:29: error: unicode/ucnv_cb.h: No such file or directory third_party/chrome/files/base/string_util_icu.cc:16:30: error: unicode/ucnv_err.h: No such file or directory
I'm assuming these files are supposed to be part of the icu38 distribution. I have a numfmt.cpp in third_party/icu38/files/source/i18n, but no numfmt.h.
I'm so sick of these Web 2.0 development efforts! Seriously, people, just stop supporting teh Web entirely! Force those who have been dragging their feet for the last 9000 YEARS to finally upgrade!
Obviously the Ranting has taken on a path of Humor, LOL. Seriously who in their right mind expects pre-built PACKAGES to all the sudden appear while something is in Beta, much less alpha. The real question is , why can't you untar something and compile it yourself, stop dragging your feet for the last 3 months and RTFM, take some time and educate your self and maybe these questions will answer themselves..............
Problems compiling on my Mac (10.6.1). XCode Version 3.2.1 (1613). Error is:
Compiling scons-out/opt-mac/obj/plugin/glue/bitmap_glue.os In file included from third_party/chrome/files/base/string16.h:32,
third_party/chrome/files/base/basictypes.h:54: error: conflicting declaration 'typedef long unsigned int uint64' /System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:53: error: 'uint64' has a previous declaration as 'typedef uint64_t uint64'Anyone else seeing these? Thanks.
i vote for 64 bit too :-)
+1 for x86_64! :-)
http://ppa.launchpad.net/ubuntu-webtech/o3d-daily/ubuntu/pool/main/o/o3d/
/usr/local/rebuild/o3d/o3d$ ./gypbuild scons: Reading SConscript files ...
scons: warning: Ignoring missing SConscript 'o3d_all_main.scons' File "/usr/local/rebuild/o3d/third_party/scons/scons.py", line 165, in <module> scons: done reading SConscript files. scons: Building targets ... scons: `.' is up to date. scons: done building targets.
Speeding up the internet won't be so relevant until you show 64bit support. After all, we are talking about 3D in a browser.. As developers are looking to move to 64 bit systems, I think it would be wise to concentrate on the new and the now.
I am not able to use 32bit libraries. If I'm on a 64bit system, I want a pure 64bit system, period -> . Anyway, great idea. Won't touch it until there's support for 64 bit support, though.
People do need to be considerate of the people who don't have 64bit computers. I know a lot of people who don't have 64bit processors. There are also several movements to recycle old hardware to help computing be more "green" or sustainable. Also, it helps people who cannot afford to buy a computer. They can go into a place like FreeGeek? in Portland, OR and build a few computers or salvage old computer parts and take a free computer home with Linux installed.
It's true that many people are buying new netbooks. I have one, and I love how portable it is. I do wish it had more processing power.
There is a 64bit computer sitting on my floor right now. It doesn't work. Someone gave it to me to see if I could fix it. They kicked it across their garage in a fit of anger one day. The processor works and the RAM checks out, but the motherboard has a crack in it.
I am am so sick of backwards compatible human evolution. People should stop being so inane like all people have been since dawn of humanity. All people should be forced to upgrade. #theSingularityIsNear #resistanceIsFutile #couldNotResist
as americanjeffbowden, same error...
People keep saying that even new netbooks are 32-bit. This is not true. Intel Atom CPUs are 64-bit:
http://ark.intel.com/Product.aspx?id=35635&processor=230&spec-codes=SLB6Z
64-bit is very much mainstream, and has been for about 8 years.
Dropping 32-bit compatibility would be stupid! In my opinion, 16-bit should have never been dropped in the first place!
For me the build was succesfuly done on my ubuntu 9.10 64bit and it works pretty well, even so i have done a Debug Build It's really a great project to have a scene graph available inside the browser Thank's for your work
I was able to build until I recently sync'ed it and now i'm getting this error:
Call to 'which dpkg-buildpackage || true' returned exit status 0.
I'm using Fedora 12 and this seems related to a debian specific program.