[arch-general] build help needed, Trinity kdebase - 2 issues on Arch
Guys, After getting kdelibs done, I have run into a wall with the building kdebase: http://websvn.kde.org/branches/trinity/kdebase/ (see bottom of page for admin and cmake links) There are 2 issues I'm having on Arch: (1) 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 \ -DCMAKE_SKIP_RPATH=ON and I have set the environment as: [[ ${PATH%%:*} =~ /opt/qt/bin ]] || export PATH=/opt/qt/bin:$PATH export CMAKE_PREFIX_PATH=/opt/qt export CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt export KDEDIR=/opt/trinity export KDEDIRS=/opt/trinity:/usr export PKG_CONFIG_PATH=:/opt/trinity/lib/pkgconfig:/opt/trinity/lib/pkgconfig:/opt/qt/lib/pkgconfig export XDG_CONFIG_DIRS=/etc/xdg:/opt/trinity/etc/xdg:/opt/trinity/etc/xdg export XDG_DATA_DIRS=/usr/share/:/usr/local/share/:/opt/trinity/share:/opt/trinity/share However, the kdebase build still fails due to grabbing the wrong qfile.h: [ 11%] Building CXX object kicker/libkicker/CMakeFiles/kickermain-shared.dir/kickerSettings.cpp.o cd /dat_e/david/bld/trinity/kdebase/src/kicker/libkicker && /usr/bin/c++ -Dkickermain_shared_EXPORTS -DHAVE_CONFIG_H -DUSE_QT3 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -march=x86-64 -mtune=generic -O2 -pipe -include tqt.h -fPIC -I/dat_e/david/bld/trinity/kdebase/src/kicker/libkicker -I/opt/trinity/include -I/opt/qt/include -I/opt/qt/include/tqt -o CMakeFiles/kickermain-shared.dir/kickerSettings.cpp.o -c /dat_e/david/bld/trinity/kdebase/src/kicker/libkicker/kickerSettings.cpp In file included from /usr/include/QtCore/QFile:1:0, from /dat_e/david/bld/trinity/kdebase/src/kicker/libkicker/kickerSettings.cpp:7: /usr/include/QtCore/qfile.h:53:1: error: ‘QT_BEGIN_HEADER’ does not name a type /usr/include/QtCore/qfile.h:62:27: error: expected initializer before ‘:’ token make[2]: *** [kicker/libkicker/CMakeFiles/kickermain-shared.dir/kickerSettings.cpp.o] Error 1 make[2]: Leaving directory `/dat_e/david/bld/trinity/kdebase/src' make[1]: *** [kicker/libkicker/CMakeFiles/kickermain-shared.dir/all] Error 2 make[1]: Leaving directory `/dat_e/david/bld/trinity/kdebase/src' make: *** [all] Error 2 Aborting... I don't know if this is due to checks in the admin/acinclude.m4.in that look for kde4 before looking for kde3 and set QTDIR or what, but I need help find a way to have cmake ignore the Qt4 /usr/include. (2) On boxes without kde4, the kdebase build proceeds fine until it hits 29% building kcontrol/iccconfig/iccconfig.cpp. From talking to the folks on the trinity list, it looks like something related to the xrandr package. Looking at the error, it looks like the build doesn't understand the type ‘KRandrSimpleAPI*’. The full build error is: [ 29%] Building CXX object kcontrol/iccconfig/CMakeFiles/kcm_iccconfig-module.dir/iccconfig.cpp.o cd /home/david/arch/pkg/tbld/kdebase/src/kcontrol/iccconfig && /usr/bin/c++ -Dkcm_iccconfig_module_EXPORTS -DHAVE_CONFIG_H -DUSE_QT3 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -march=i686 -mtune=generic -O2 -pipe -include tqt.h -fPIC -I/home/david/arch/pkg/tbld/kdebase/src/kcontrol/iccconfig -I/home/david/arch/pkg/tbld/kdebase/src -I/opt/trinity/include -I/opt/qt/include -I/opt/qt/include/tqt -DKDE_CONFDIR=\"/opt/trinity/share/config\" -o CMakeFiles/kcm_iccconfig-module.dir/iccconfig.cpp.o -c /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp: In member function ‘void KICCConfig::load(bool)’: /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:289:38: error: expected type-specifier /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:289:38: error: cannot convert ‘int*’ to ‘KRandrSimpleAPI*’ in initialization /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:289:38: error: expected ‘,’ or ‘;’ /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp: In member function ‘virtual void KICCConfig::save()’: /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:359:37: error: expected type-specifier /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:359:37: error: cannot convert ‘int*’ to ‘KRandrSimpleAPI*’ in initialization /home/david/arch/pkg/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:359:37: error: expected ‘,’ or ‘;’ make[2]: *** [kcontrol/iccconfig/CMakeFiles/kcm_iccconfig-module.dir/iccconfig.cpp.o] Error 1 make[2]: Leaving directory `/home/david/arch/pkg/tbld/kdebase/src' make[1]: *** [kcontrol/iccconfig/CMakeFiles/kcm_iccconfig-module.dir/all] Error 2 make[1]: Leaving directory `/home/david/arch/pkg/tbld/kdebase/src' make: *** [all] Error 2 Aborting... Solving this type of build issue, I will need a bit of expertise from the list. I have googled until I'm blue trying to find a trick to get past these issues, but I'm stuck. Any ideas from the cpp/cmake/make experts? Even narrowing down what I need to look for will help. Current PKGBUILDs for tqtinterface, arts, kdelibs and the current one I'm using for kdebase are available on the wiki: https://wiki.archlinux.org/index.php/Trinity#Trinity_PKGBUILDs Thanks. -- David C. Rankin, J.D.,P.E.
On 5 February 2011 04:10, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
After getting kdelibs done, I have run into a wall with the building kdebase:
http://websvn.kde.org/branches/trinity/kdebase/ (see bottom of page for admin and cmake links)
There are 2 issues I'm having on Arch:
(1) If kde4/Qt4 is installed, cmake fails when it uses /usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
I haven't read the whole message but for now a quick tip: could you run ccmake after cmake and check all the paths? Remember to toggle on advanced view in there.
On 02/04/2011 04:26 PM, Ray Rashif wrote:
On 5 February 2011 04:10, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
After getting kdelibs done, I have run into a wall with the building kdebase:
http://websvn.kde.org/branches/trinity/kdebase/ (see bottom of page for admin and cmake links)
There are 2 issues I'm having on Arch:
(1) If kde4/Qt4 is installed, cmake fails when it uses /usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
I haven't read the whole message but for now a quick tip: could you run ccmake after cmake and check all the paths? Remember to toggle on advanced view in there.
I'll give it a go. I'm completely new to solving cmake problems, so I need to make friend with ccmake. Also, it was just suggested on the trinity list to try building in a virtual machine or in a chroot to try and get around the potential for Qt4 uic problems. I know virtualbox, but would it be easier to try to build in a chroot? I can chroot my OS to get around kernel failures, etc.., but I have 'zero' experience setting one up for building packages. Looking around, it looks like I can either use chroot, schroot, or mkarchroot. But without any experience with them, I don't know which path to go down first. So you have any guidance on the following: (1) use vbox? or (2) use a chroot? -- if so, what's the best tool for a project like packaging Trinity? chroot, schroot, mkarchroot? -- also, if a chroot is best, any favorite links for configuring it? Thanks Ray! -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 5 February 2011 08:34, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
(1) use vbox?
or
(2) use a chroot?
(2) pacman -S devtools extra-i686-build (in PKGBUILD dir) That makes use of mkarchroot and makechrootpkg [1], which makes use of chroot. 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...
On 02/04/2011 07:21 PM, Ray Rashif wrote:
On 5 February 2011 08:34, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
(1) use vbox?
or
(2) use a chroot?
(2)
pacman -S devtools extra-i686-build (in PKGBUILD dir)
That makes use of mkarchroot and makechrootpkg [1], which makes use of chroot.
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...
Thank you Ray, I'll get it setup. Just a note on devtools, /usr/bin/communitypkg conflicts with the same package from aurtools. I removed aurtools, but wonder if a conflicts() shouldn't be added to the devtools PKGBUILD? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 05/02/11 11:48, David C. Rankin wrote:
On 02/04/2011 07:21 PM, Ray Rashif wrote:
On 5 February 2011 08:34, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
(1) use vbox?
or
(2) use a chroot?
(2)
pacman -S devtools extra-i686-build (in PKGBUILD dir)
That makes use of mkarchroot and makechrootpkg [1], which makes use of chroot.
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...
Thank you Ray, I'll get it setup.
Just a note on devtools, /usr/bin/communitypkg conflicts with the same package from aurtools. I removed aurtools, but wonder if a conflicts() shouldn't be added to the devtools PKGBUILD?
Nope... aurtools is not a supported package. And I have no idea why it has communitypkg in it. Allan
On 02/04/2011 07:21 PM, Ray Rashif wrote:
On 5 February 2011 08:34, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
(1) use vbox?
or
(2) use a chroot?
(2)
pacman -S devtools extra-i686-build (in PKGBUILD dir)
That makes use of mkarchroot and makechrootpkg [1], which makes use of chroot.
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...
Ray, Allan, All, I got mkarchroot setup in /dat_e/david/bld/root and I created a custom repo with all necessary dependency packages for the Trinity kdebase build in /dat_e/david/bld/root/chrepo and added the repo to ..bld/root/etc/pacman.conf and updated the mkarchroot. (I ran a test by building rpncalc from AUR and it worked perfectly) I have my copy of kdebase in /dat_e/david/bld/tmp/kdebase. Running sudo makechrootpkg -r /dat_e/david/bld installs all the dependencies and all the previously built trinity packages just fine. But then cmake fails before it even starts for the kdebase build with the following: 21:02 archangel:/dat_e/david/bld/tmp/kdebase> sudo makechrootpkg -r /dat_e/david/bld ==> Making package: trinity 9999-1.0 (Sat Feb 5 03:02:26 UTC 2011) ==> Checking Runtime Dependencies... ==> Checking Buildtime Dependencies... ==> Retrieving Sources... ==> Extracting Sources... ==> Starting build()... CMake Error: The source directory "/build" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI. Aborting... Build failed, check /dat_e/david/bld/copy/build I see that /dat_e/david/bld/copy holds a copy of the chroot and /dat_e/david/bld/copy/build holds the PKGBUILD pkg, and src dirs. But cmake is obviously not happy with the setup. CMakeList.txt is in my source kdebase dir, but not the root or copy directories created by mkarchrootpkg. Is there something I need to modify or change in PKGBUILD or the mkarchroot setup to have it work with cmake?? Any help appreciated. -- David C. Rankin, J.D.,P.E.
On 02/04/2011 09:19 PM, David C. Rankin wrote:
21:02 archangel:/dat_e/david/bld/tmp/kdebase> sudo makechrootpkg -r /dat_e/david/bld ==> Making package: trinity 9999-1.0 (Sat Feb 5 03:02:26 UTC 2011) ==> Checking Runtime Dependencies... ==> Checking Buildtime Dependencies... ==> Retrieving Sources... ==> Extracting Sources... ==> Starting build()... CMake Error: The source directory "/build" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI. Aborting... Build failed, check /dat_e/david/bld/copy/build
I see that /dat_e/david/bld/copy holds a copy of the chroot and /dat_e/david/bld/copy/build holds the PKGBUILD pkg, and src dirs. But cmake is obviously not happy with the setup. CMakeList.txt is in my source kdebase dir, but not the root or copy directories created by mkarchrootpkg. Is there something I need to modify or change in PKGBUILD or the mkarchroot setup to have it work with cmake??
Any help appreciated.
I think this has to do with the fact that I'm building from a svn tree and not a tarball. The existing kdebase directory I'm building from look like this: <snip> drwxr-xr-x 6 david david 4096 Jan 25 13:46 libkonq drwxr-xr-x 7 david david 4096 Jan 25 13:46 nsplugins drwxr-xr-x 5 david david 4096 Jan 25 13:46 pics -rw-r--r-- 1 david david 127 Oct 11 16:53 AUTHORS -rw-r--r-- 1 david david 7480 Jan 25 13:47 CMakeLists.txt -rw-r--r-- 1 david david 18273 Jan 18 09:52 COPYING -rw-r--r-- 1 david david 20403 Jan 18 09:52 COPYING-DOCS -rw-r--r-- 1 david david 4077 Jan 25 13:47 ConfigureChecks.cmake -rw-r--r-- 1 david david 7966 Jan 18 09:52 INSTALL -rw-r--r-- 1 david david 429 Oct 11 16:53 Mainpage.dox -rw-r--r-- 1 david david 514 Oct 11 16:53 Makefile.am.in -rw-r--r-- 1 david david 451 Oct 11 16:53 Makefile.cvs -rw-r--r-- 1 david david 1547 Feb 4 13:07 PKGBUILD -rw-r--r-- 1 david david 9035 Jan 18 09:52 README -rw-r--r-- 1 david david 2914 Oct 11 16:53 README.pam -rw-r--r-- 1 david david 3056 Jan 25 13:47 config.h.cmake -rw-r--r-- 1 david david 811 Oct 11 16:53 configure.in.bot -rw-r--r-- 1 david david 8591 Oct 11 16:53 configure.in.in -rw-r--r-- 1 david david 333 Oct 11 16:53 kde.pamd -rw-r--r-- 1 david david 266 Oct 11 16:53 kde3 -rw-r--r-- 1 david david 347 Oct 11 16:53 kdebase.lsm -rw-r--r-- 1 david david 214 Oct 11 16:53 kscreensaver.pamd -rwxr-xr-x 1 david david 2410 Oct 11 16:53 mkpamserv -rw-r--r-- 1 david david 20934 Jan 18 09:52 startkde How do I tell makechrootpkg to use the files in the same directory as the PKGBUILD? In the PKGBUILD I simply have: source=() for the source with works fine when running makepkg, but is somehow failing to copy the files to /dat_e/david/bld/copy/build/ when run with makechrootpkg. It is like I need a way to tell makechrootpkg to send source=(all files in the same dir as PKGBUILD) to makepkg. I could specify an explicit list of directories and files in the PKGBUILD source(), but that seems strange. What say the gurus? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 4 February 2011 23:02, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
How do I tell makechrootpkg to use the files in the same directory as the PKGBUILD? In the PKGBUILD I simply have:
Why is the checkout in the same directory as the PKGBUILD? Have a look at /usr/share/pacman/PKGBUILD-svn.proto, and every -svn package in the repos/AUR. The checkout happens into src/trinity (for example), which is copied to src/trinity-build, where the build takes place. -- Tavian Barnes
On 02/06/2011 10:49 AM, Tavian Barnes wrote:
On 4 February 2011 23:02, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
How do I tell makechrootpkg to use the files in the same directory as the PKGBUILD? In the PKGBUILD I simply have:
Why is the checkout in the same directory as the PKGBUILD? Have a look at /usr/share/pacman/PKGBUILD-svn.proto, and every -svn package in the repos/AUR. The checkout happens into src/trinity (for example), which is copied to src/trinity-build, where the build takes place.
Tavian, thanks for your suggestion. For trinity, the whole svn tree is already on my computer: ~/tbld/trinity ~/tbld/trinity/dependencies ~/tbld/trinity/dependencies/tqtinterface ~/tbld/trinity/dependencies/arts ~/tbld/trinity/kdelibs <snip> I have the PKGBUILDs each trinity module directory (eg. {tqtinterface,arts,kdelibs,etc...} ) So there is no 'svn checkout' performed from within the PKGBUILDs. For example, each directory is similar to the following: 20:35 alchemy:~/tbld/trinity/kdelibs> ls -1 admin arts cmake dcop <snip> CMakeLists.txt <snip> PKGBUILD <snip> From ${srcdir}, cmake is called by: cmake ../ This fails with makechrootpkg because nothing gets copied to the chroot. Is there a way to fix this? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 7 February 2011 10:38, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
This fails with makechrootpkg because nothing gets copied to the chroot. Is there a way to fix this?
Yes, the copying is "hardcoded". Things in the source array are copied, and along with those additionally the changelog and install scriptlet. See line 170 onwards of makechrootpkg. Unfortunately, aside from directly editing makechrootpkg itself, I don't see how to 'fix' this. Maybe if you changed the way you're going about doing the builds..but I'll have to look a little deeper to actually comment any further.
On 02/06/2011 09:05 PM, Ray Rashif wrote:
On 7 February 2011 10:38, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
This fails with makechrootpkg because nothing gets copied to the chroot. Is there a way to fix this?
Yes, the copying is "hardcoded". Things in the source array are copied, and along with those additionally the changelog and install scriptlet. See line 170 onwards of makechrootpkg.
Unfortunately, aside from directly editing makechrootpkg itself, I don't see how to 'fix' this. Maybe if you changed the way you're going about doing the builds..but I'll have to look a little deeper to actually comment any further.
Thanks Ray, I could shoot myself. I originally did the PKGBUILDs to do a svn checkout in src, but then didn't want to re-download a complete copy of the tree every time makepkg was run. I was using a snvversion test on the .svn/entries to see if a new version existed, but that didn't do what I wanted. The good news is that adding the code to the PKGBUILD to have them do a svn checkout is a simple 5-10 lines at the top of each PKGBUILD. My overall goal was to write a shell script that would take the standard trinity svn checkout, add the PKGBUILDs, then loop through the modules in the proper build order to provide a complete build of trinity for those that don't want to use the binary packages. Easier on the dev to. Just kick off a build, go do something else, check back, still running, go do something else.... or stop and fix what broke. I guess I was using a 'tree' focused approach: Saying "I have the tree", now let's do PKGBUILDs for the tree and then tie them together with a master build script. The alternative would be the PKGBUILD focused approach: Saying "Let's build PKGBUILDs to retrieve their part of Trinity via svn and if we build them all, then we will have the whole svn tree after we build the las module. I originally shied away from this approach in order to use the simple 'svn up *' in the trinity base directory to coordinate updates to all modules and eliminate the possibility that the download of a single module and update there may put it out of sync with the rest of the tree if dependent packages below it received updates relied upon by the module you are working on. The makearchroot tool may be what drives me back to this approach. I can get i686 done in VBox, but I can't do x86_64 in Virtualbox even on a 64-bit box. So makearchroot work for the 'in source' build would be ideal. Too bad I can't just define srcdir as '../' such that the existing svn source would get into the chroot. Ideas? -- David C. Rankin, J.D., P.E.
On 02/06/2011 10:33 PM, David C. Rankin wrote:
The makearchroot tool may be what drives me back to this approach. I can get i686 done in VBox, but I can't do x86_64 in Virtualbox even on a 64-bit box. So makearchroot work for the 'in source' build would be ideal.
Correction - I think I can... I have a 64-bit vbox install on my laptop now :) -- David C. Rankin, J.D., P.E.
participants (4)
-
Allan McRae
-
David C. Rankin
-
Ray Rashif
-
Tavian Barnes