Calvin wrote:
On an Intel Atom it takes much longer than 5 minutes :P It broke again D:
Do you think it is related to the environmental variables?
Hmmm..
(1.) The very first thing I want to do is confirm that you have the following built and installed in this order, so show us 'pacman -Q | grep trinity':
15:34 supersff:~> pacman -Q | grep trinity # then I manually sorted
trinity-qt3 3.3.8-20 trinity-pyqt3 3.18.1-9 trinity-tqtinterface 1221148-1 trinity-arts 1214641-1 trinity-kdelibs 1222098-1
Your stuck at 37% on
trinity-kdebase 1221588-1
(2.) Please post the error you received after rebuilding with 'make VERBOSE=1' in the build() function. (it will provide a little more info that will help)
Your environment for the build is set within the PKGBUILD file so it shouldn't matter what your existing shell environment is:
export CMAKE_PREFIX_PATH=/opt/qt:/opt/trinity
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr export LD_LIBRARY_PATH=/opt/trinity/lib:/opt/trinity/lib/kde3:$LD_LIBRARY_PATH export PKG_CONFIG_PATH=:/opt/trinity/lib/pkgconfig:/opt/qt/lib/pkgconfig
The build environment will be influenced by /etc/ld.so.conf.d/trinity-kdelibs.conf. So if you have trinity-kdelibs installed:
(3.) confirm you have
cat /etc/ld.so.conf.d/trinity-kdelibs.conf /opt/trinity/lib
(4.) As root, run ldconfig if the trinity-kdelibs.conf so the linker cache magic is updated.
What I want to confirm is that you are NOT trying to build on a system with KDE4/Qt4 or kdemod3 installed. That will screw up your build because of the conflicting libraries that cmake has trouble ignoring. So:
(5.) look at:
pacman -Q | grep "qt|kde"
If you have:
qt 4.7.1-3 kdemod3-<anything> 3.5.10-1 kde<xyz>-<anything> 4.6.0-2
The build will fail.
I don't know how a build between a normal i686, x86_64 and an Intel Atom will differ, but I haven't heard anything that says building on an Intel Atom won't work -- or that it *will* work for that matter. So let's take it step by step.
Change into
trinity-qt3
do 'makepkg -sf --noextract' to do a quick rebuild of the existing package and install it with 'sudo pacman -U trinity-qt3-<version>.xz.
do the same thing for trinity-pyqt3
Change into
trinity-tqtinterface - a simple makepkg -sf and install with 'sudo pacman -U trinity-tqtinterface-<version>.xz.
Do the same thing for 'trinity-arts' and 'trinity-kdelibs'. After 'trinity-kdelibs' is installed - and run (as root) ldconfig.
(6.) Change into
trinity-kdebase - and restart the build with 'make VERBOSE=1' and post the output if it fails again.
I'm scratching my head on this one. I've literally built Trinity 5-6 times in the past 2 days using the build script and gotten no errors during the make. So the PKGBUILDs work. If there is something special we need to do for the Intel Atom, then that's something we will have to look into. But, to get started, we need the information requesting in (1.) - (6.) above :)
On 02/22/2011 03:58 PM, David C. Rankin wrote:
Calvin wrote:
On an Intel Atom it takes much longer than 5 minutes :P It broke again D:
Do you think it is related to the environmental variables?
Hmmm..
<snip>
Calvin, I have found a missing export. Change:
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
to
export CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
I'm updating the PKGBUILD now :) (long lines - must have deleted an export accidentally :(
On 02/22/2011 04:24 PM, David C. Rankin wrote:
On 02/22/2011 03:58 PM, David C. Rankin wrote: Calvin, I have found a missing export. Change:
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
to
export CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
<snip>
Calvin,
I just ran another build - no problems :) Here is the bldlog.txt file from the latest build:
http://www.3111skyline.com/dl/dt/trinity/tmp/bldlog.txt
I suspect that the CMAKE_INCLUDE_PATH gave me no problems due to already having Trinity installed and pkgconfig taking care of the path for me. Let me know if you have gotten kdebase to build.
The current package list on i686 is:
17:24 supersff:~/tblds> pacman -Q | grep trinity trinity-arts 1214641-1 trinity-kdebase 1221588-1 trinity-kdelibs 1222098-1 trinity-kdevelop 1221512-1 trinity-kdewebdev 1216789-1 trinity-pyqt3 3.18.1-9 trinity-qt3 3.3.8-20 trinity-tqtinterface 1221148-1
Well long story short, I am glad that it works for you. but if more than one person can't build it, the whole PKGBUILD system becomes worthless.
Thanks for updating the PKGBUILD i'll take a look at it.
I do have qt4 installed (hmm you seem to have mentioned that before) BUT that shouldn't interfere with it afaik.
On 22 February 2011 18:28, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/22/2011 04:24 PM, David C. Rankin wrote:
On 02/22/2011 03:58 PM, David C. Rankin wrote: Calvin, I have found a missing export. Change:
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
to
export CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
<snip>
Calvin,
I just ran another build - no problems :) Here is the bldlog.txt file from the latest build:
http://www.3111skyline.com/dl/dt/trinity/tmp/bldlog.txt
I suspect that the CMAKE_INCLUDE_PATH gave me no problems due to already having Trinity installed and pkgconfig taking care of the path for me. Let me know if you have gotten kdebase to build.
The current package list on i686 is:
17:24 supersff:~/tblds> pacman -Q | grep trinity trinity-arts 1214641-1 trinity-kdebase 1221588-1 trinity-kdelibs 1222098-1 trinity-kdevelop 1221512-1 trinity-kdewebdev 1216789-1 trinity-pyqt3 3.18.1-9 trinity-qt3 3.3.8-20 trinity-tqtinterface 1221148-1
-- 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
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.
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
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
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
On 02/22/2011 07:46 PM, calvin morrison wrote:
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
YES - Amen. This is how it needs to be done.
I have no doubt that the Trinity cmake files will ultimately get tailored to do this correctly. But I understand the priorities. These tweaks lie somewhere on the time-line between:
+-------------------------------|------------------------------------+ Port all Modules Tweak CMake files Finished Trinity to CMake and to ignore other 3.5.13 Super get building in existing packages Desktop clean environ possibly present
(** Not to scale :-)
On 02/22/2011 07:02 PM, calvin morrison wrote:
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
I think all of this can be handled in the CMake files, but it will take detailed effort from somebody way smarter than I am to insure the CMake build process only uses the proper Qt version and proper libraries associated with the DCMAKE_INSTALL_PREFIX=${trinity_prefix}, -DWITH_QT3=ON, -DQTDIR=/opt/qt or similar options.
I know cmake can do it, I just don't know how or where to tell it to do it :( That's why after fighting the weird build errors and trying to prevent the build from looking in /usr for includes and Qt libraries, I just threw in the towel and set up a clean build environment. (it also let me catch all needed dependencies and specify them in the PKGBUILDs)