On 22/02/2011, calvin morrison mutantturkey@gmail.com wrote:
On 22/02/2011, calvin morrison mutantturkey@gmail.com wrote:
On 22/02/2011, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/22/2011 05:49 PM, calvin morrison wrote:
I do have qt4 installed (hmm you seem to have mentioned that before) BUT that shouldn't interfere with it afaik.
Oh yes it will :(
There are several problems, see thread:
[trinity-users] kdebase make failure if Qt4 installed, QtCore/qfile.h QT_BEGIN_HEADER doesn't name type
There are 2 big ones, cmake will not ignore Qt4 uic and end up trying to use it instead of uic from trinity. (you can try and trick it by putting /opt/qt/bin:/opt/trinity/bin/ before /usr in your path, but that is a risky hack.
Then there is:
<quote> If kde4/Qt4 is installed, cmake fails when it uses /usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
I cannot figure out how to tell cmake to ignore the /usr/include. I have tried the cmake arguments:
cmake ../ \ -DCMAKE_INSTALL_PREFIX=${trinity_prefix} \ -DWITH_QT3=ON \ -DQTDIR=/opt/qt \ -DBUILD_ALL=ON
</quote>
<reply> They are right, some KDE3 applications where no amount of configuration helps only build properly in a clean chroot, without the KDE4 stuff around.
https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroo...
</reply>
So even though you can *INSTALL* Trinity next to kde4, that doesn't mean you can *BUILD* Trinity next to kde4 :) Same goes for Qt4. If you are building trinity based on Qt3, just because you can *INSTALL* a Qt3 based Trinity on a system with Qt4 present, it doesn't mean you can *BUILD* a Qt3 based Trinity with Qt4 present :)
The PKGBUILD files are correct, but they don't work magic :p
Set up a clean build environment in VirtualBox. Alocate ~15G to the install, (you could probably get away with 8G total). For a 15G VM allocate 5G '/', 120M '/boot', the rest '/home'. The basic Arch install takes ~ 10 minutes to install base and base-devel packages and all you have to do is hit 'return' and the Arch defaults for partitioning, etc. are fine.
Then what I did was just to setup my existing /home/david dir as a shared folder in VirtualBox to provide access to all my files and provide a place to save finished packages so they exist outside the VM. Then in the VirtualBox guest install of Arch, just create your /home/calvin/builds, set the paths for the bldtrinsvn-all.sh to use that as your builds dir and point the srcdir and pkgdir path to the shared folder on your original /home/calvin that you shared with your guest as something like 'hhome' (short for host home) and start building.
No whacky kde4/kde3 lib conflicts and no Qt4/Qt3 header file conflicts.
Some software just needs a clean build environment to build properly. It has nothing to do with running it, it just has to build without the presents of conflicting files.
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
It seems this is a case where we would need a make-conflict. but that doesn't exist in PKGBUILDs arrays. Fogobogo suggest that we add it to our make depends and require that (qt < 4).
Can we resolve this issue another way? Calvin
It seems also that we can ignore libs with cmake!
http://www.mail-archive.com/cmake@cmake.org/msg09583.html
/NODEFAULTLIB maybe the answer to the problem.
I have yet to find how to use this (unfimiliar with cmake)
Calvin
So I've worked out (sorry for triple posting) what the tentative solution is,
cmake documentation says: CMAKE_EXE_LINKER_FLAGS: Linker flags used to create executables. Flags used by the linker when creating an executable.
So all we have to do is set the flags right for ld to ignore the Qt4 libs.
ld has a option " -z nodefaultlib " once i figure out how this works, all we have to do is add another export line for the CMAKE_EXE_LINKER_FLAGS and that should fix the problem AFAIK.
Calvin