trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2011

Re: [trinity-devel] Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]

From: "David C. Rankin" <drankinatty@...>
Date: Wed, 23 Feb 2011 18:09:42 -0600
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.