On 02/23/2011 05:26 PM, PICCORO McKAY Lenz wrote: > please, stop this imprudence! Linux on Virtual Machine! use real! and the lest > see, oh good! > > downgrade glibc 2.13 to 2.10 or 2.11, its clarely these imprudence to run on > virtual machine are memory coruption! OK - no more imprudence :) The need to use VM is caused by current condition of Trinity CMake files that will not ignore existing KDE4/Qt4 or KDE3 includes or libraries requiring you to either setup a whole new clean install on an existing computer or build in a VM. So far building in the VM has worked *perfectly*. I see limitation of the VM builds with this x86_64 memory problem. But to build for both x86_64 with the current CMake files, if you don't build in a VM, that means you have to setup 2 new clean Linux installs. I don't mind doing it because I have boxes to spare. But the CMake files need to be updated to build on a system with existing KDE4/Qt4 or KDE3 installs so that you can build Trinity without needing to do separate clean installs to provide a clean build environment. Other things I've learned is that building in a chroot is not a simple solution due to the multiple layers of dependencies needed by each successive package. The dependencies are normal, but maintaining the chroot environment becomes difficult very quickly as package No. 5, 6, 7, etc. are built and installed - at least on Arch with the Xen kernel chroot. I've setup an i686 box dedicated to Trinity building and I'll do the same on another x86_64 box, but it would sure be much easier to build, if we found a way to tailor the Trinity CMake files to ignore the foreseeable conflicting includes and libraries present with existing KDE4/Qt4 and KDE3 installs :) Calvin has dug up some interesting CMake variables that may be needed to do this: /NODEFAULTLIB CMAKE_EXE_LINKER_FLAGS (probably many more...) I know nothing about them, but if we can get the CMake files to just look at the libraries and includes provided by the Trinity: Qt3, tqtinterface, arts, kdelibs, kdebase, etc... files, then we could dispense with needing to create new installs or VMs to get Trinity to build... I know where this sits in the timeline, but it may be worth a look to see how difficult a cleanup to fix the library and include issue would be :) -- David C. Rankin, J.D.,P.E.