I'm trying to resolve bug report 756.
I noticed FAM support is not provided in the build process. I conjured up this patch:
============================= diff -urN kdelibs/CMakeLists.txt kdelibs.new/CMakeLists.txt --- kdelibs/CMakeLists.txt 2011-10-29 15:47:19.000000000 -0500 +++ kdelibs.new/CMakeLists.txt 2012-01-14 19:35:33.000000000 -0600 @@ -736,6 +736,14 @@ endif( WITH_HSPELL )
+##### check for FAM/GAMIN ########################## + +check_include_file( "fam.h" HAVE_FAM_H ) +if( HAVE_FAM_H ) + set( HAVE_FAM 1 ) +endif( HAVE_FAM_H ) + + ##### write configure files #####################
configure_file( config.h.cmake config.h ) diff -urN kdelibs/config.h.cmake kdelibs.new/config.h.cmake --- kdelibs/config.h.cmake 2011-08-10 21:30:27.000000000 -0500 +++ kdelibs.new/config.h.cmake 2012-01-14 19:42:56.000000000 -0600 @@ -114,7 +114,7 @@ #undef HAVE_FADVISE
/* Define if your system has libfam */ -#undef HAVE_FAM +#cmakedefine HAVE_FAM 1
/* Define to 1 if you have the <float.h> header file. */ #cmakedefine HAVE_FLOAT_H 1 =============================
kdelibs fails to build with that patch:
============================= kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:241: undefined reference to `FAMOpen' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:241: undefined reference to `FAMOpen' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::removeEntry(KDirWatch*, QString const&, KDirWatchPrivate::Entry*)': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:935: undefined reference to `FAMCancelMonitor' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::checkFAMEvent(FAMEvent*)': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:1502: undefined reference to `FAMCancelMonitor' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::famEventReceived()': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:1410: undefined reference to `FAMPending' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:1411: undefined reference to `FAMNextEvent' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::useFAM(KDirWatchPrivate::Entry*)': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:613: undefined reference to `FAMMonitorFile' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:595: undefined reference to `FAMMonitorDirectory' kio/libksycoca.a(kdirwatch.cpp.o): In function `~KDirWatchPrivate': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:356: undefined reference to `FAMClose' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:356: undefined reference to `FAMClose' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:356: undefined reference to `FAMClose' collect2: ld returned 1 exit status make[2]: *** [kio/libkio.so.4.2.0] Error 1 make[2]: Leaving directory `/dev/shm/kdelibs.build' make[1]: *** [kio/CMakeFiles/kio-shared.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/dev/shm/kdelibs.build' /usr/bin/cmake -E cmake_progress_report /dev/shm/kdelibs.build/CMakeFiles [ 58%] Built target kdeprint_tool_escputil-module Linking CXX executable artsmessage cd /dev/shm/kdelibs.build/arts/message && /usr/bin/cmake -E cmake_link_script CMakeFiles/artsmessage.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -march=i486 -mtune=i686 -ggdb -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h CMakeFiles/artsmessage.dir/artsmessage.cc.o -o artsmessage -rdynamic -L/opt/trinity/lib/qt3-3.3.8.d/lib ../../kdeui/libkdeui.so.4.2.0 ../../kdecore/libkdecore.so.4.2.0 ../../dcop/libDCOP.so.4.2.0 ../../kdefx/libkdefx.so.4.2.0 -ltqt -lqt-mt -lXrender -lX11 -lz -lidn -lXcomposite -lXfixes -lICE -lSM -lfreetype -lfontconfig -Wl,-rpath,/opt/trinity/lib/qt3-3.3.8.d/lib:/dev/shm/kdelibs.build/kdeui:/dev/shm/kdelibs.build/kdecore:/dev/shm/kdelibs.build/dcop:/dev/shm/kdelibs.build/kdefx: make[2]: Leaving directory `/dev/shm/kdelibs.build' /usr/bin/cmake -E cmake_progress_report /dev/shm/kdelibs.build/CMakeFiles [ 58%] Built target artsmessage make[1]: Leaving directory `/dev/shm/kdelibs.build' make: *** [all] Error 2 =============================
The header includes look correct so I'm guessing a linker problem.
Ideas?
Darrell
On Sat, 14 Jan 2012 19:06:05 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
I'm trying to resolve bug report 756.
I noticed FAM support is not provided in the build process. I conjured up this patch:
============================= diff -urN kdelibs/CMakeLists.txt kdelibs.new/CMakeLists.txt --- kdelibs/CMakeLists.txt 2011-10-29 15:47:19.000000000 -0500 +++ kdelibs.new/CMakeLists.txt 2012-01-14 19:35:33.000000000 -0600 @@ -736,6 +736,14 @@ endif( WITH_HSPELL )
+##### check for FAM/GAMIN ##########################
+check_include_file( "fam.h" HAVE_FAM_H ) +if( HAVE_FAM_H )
- set( HAVE_FAM 1 )
+endif( HAVE_FAM_H )
##### write configure files #####################
configure_file( config.h.cmake config.h ) diff -urN kdelibs/config.h.cmake kdelibs.new/config.h.cmake --- kdelibs/config.h.cmake 2011-08-10 21:30:27.000000000 -0500 +++ kdelibs.new/config.h.cmake 2012-01-14 19:42:56.000000000 -0600 @@ -114,7 +114,7 @@ #undef HAVE_FADVISE
/* Define if your system has libfam */ -#undef HAVE_FAM +#cmakedefine HAVE_FAM 1
/* Define to 1 if you have the <float.h> header file. */
#cmakedefine HAVE_FLOAT_H 1
kdelibs fails to build with that patch:
============================= kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:241: undefined reference to `FAMOpen' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:241: undefined reference to `FAMOpen' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::removeEntry(KDirWatch*, QString const&, KDirWatchPrivate::Entry*)': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:935: undefined reference to `FAMCancelMonitor' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::checkFAMEvent(FAMEvent*)': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:1502: undefined reference to `FAMCancelMonitor' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::famEventReceived()': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:1410: undefined reference to `FAMPending' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:1411: undefined reference to `FAMNextEvent' kio/libksycoca.a(kdirwatch.cpp.o): In function `KDirWatchPrivate::useFAM(KDirWatchPrivate::Entry*)': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:613: undefined reference to `FAMMonitorFile' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:595: undefined reference to `FAMMonitorDirectory' kio/libksycoca.a(kdirwatch.cpp.o): In function `~KDirWatchPrivate': /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:356: undefined reference to `FAMClose' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:356: undefined reference to `FAMClose' /dev/shm/kdelibs/kio/kio/kdirwatch.cpp:356: undefined reference to `FAMClose' collect2: ld returned 1 exit status make[2]: *** [kio/libkio.so.4.2.0] Error 1 make[2]: Leaving directory `/dev/shm/kdelibs.build' make[1]: *** [kio/CMakeFiles/kio-shared.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/dev/shm/kdelibs.build' /usr/bin/cmake -E cmake_progress_report /dev/shm/kdelibs.build/CMakeFiles [ 58%] Built target kdeprint_tool_escputil-module Linking CXX executable artsmessage cd /dev/shm/kdelibs.build/arts/message && /usr/bin/cmake -E cmake_link_script CMakeFiles/artsmessage.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -march=i486 -mtune=i686 -ggdb -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h CMakeFiles/artsmessage.dir/artsmessage.cc.o -o artsmessage -rdynamic -L/opt/trinity/lib/qt3-3.3.8.d/lib ../../kdeui/libkdeui.so.4.2.0 ../../kdecore/libkdecore.so.4.2.0 ../../dcop/libDCOP.so.4.2.0 ../../kdefx/libkdefx.so.4.2.0 -ltqt -lqt-mt -lXrender -lX11 -lz -lidn -lXcomposite -lXfixes -lICE -lSM -lfreetype -lfontconfig -Wl,-rpath,/opt/trinity/lib/qt3-3.3.8.d/lib:/dev/shm/kdelibs.build/kdeui:/dev/shm/kdelibs.build/kdecore:/dev/shm/kdelibs.build/dcop:/dev/shm/kdelibs.build/kdefx: make[2]: Leaving directory `/dev/shm/kdelibs.build' /usr/bin/cmake -E cmake_progress_report /dev/shm/kdelibs.build/CMakeFiles [ 58%] Built target artsmessage make[1]: Leaving directory `/dev/shm/kdelibs.build' make: *** [all] Error 2 =============================
The header includes look correct so I'm guessing a linker problem.
Ideas?
You need to link to libfam.so or libgamin-1.so. I don't know how to do the CMake wizardry right but if pkg-config is to be used both fam and gamin shall be checked in the CMakeLists.txt.
Darrell
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
The header includes look correct so I'm guessing a
linker problem.
Ideas?
You need to link to libfam.so or libgamin-1.so. I don't know how to do the CMake wizardry right but if pkg-config is to be used both fam and gamin shall be checked in the CMakeLists.txt.
I won't pretend to fully understand much about cmake, but I took an educated guess and updated my patch to use the pkg_search_module function, but no success. :(
============================================================= diff -urN kdelibs/CMakeLists.txt kdelibs.new/CMakeLists.txt --- kdelibs/CMakeLists.txt 2011-10-29 15:47:19.000000000 -0500 +++ kdelibs.new/CMakeLists.txt 2012-01-14 22:21:09.000000000 -0600 @@ -736,6 +736,17 @@ endif( WITH_HSPELL )
+##### check for FAM/GAMIN ########################## + +check_include_file( "fam.h" HAVE_FAM_H ) +if( HAVE_FAM_H ) + pkg_search_module( FAM gamin ) + if( FAM_FOUND ) + set( HAVE_FAM 1 ) + endif( FAM_FOUND ) +endif( HAVE_FAM_H ) + + ##### write configure files #####################
configure_file( config.h.cmake config.h ) diff -urN kdelibs/config.h.cmake kdelibs.new/config.h.cmake --- kdelibs/config.h.cmake 2011-08-10 21:30:27.000000000 -0500 +++ kdelibs.new/config.h.cmake 2012-01-14 19:42:56.000000000 -0600 @@ -114,7 +114,7 @@ #undef HAVE_FADVISE
/* Define if your system has libfam */ -#undef HAVE_FAM +#cmakedefine HAVE_FAM 1
/* Define to 1 if you have the <float.h> header file. */ #cmakedefine HAVE_FLOAT_H 1 =============================================================
Darrell
The header includes look correct so I'm guessing a
linker problem.
Ideas?
You need to link to libfam.so or libgamin-1.so. I don't know how to do the CMake wizardry right but if pkg-config is to be used both fam and gamin shall be checked in the CMakeLists.txt.
I won't pretend to fully understand much about cmake, but I took an educated guess and updated my patch to use the pkg_search_module function, but no success. :(
Try the attached patch. Ubuntu doesn't use gamin and I haven't noticed the problems you are experiencing with respect to files not showing up, but it is a good idea to enable this feature nevertheless.
Tim
Try the attached patch. Ubuntu doesn't use gamin and I haven't noticed the problems you are experiencing with respect to files not showing up, but it is a good idea to enable this feature nevertheless.
Thanks Tim!
I see that I was close but still have much to learn. :)
The package now builds. I'll report in the bugzilla my testing results.
BTW, I think this is an example of why we should keep the automake files in the GIT tree even after converting to cmake, at least for a few more Trinity releases. Those files provide us a historical record. In this case, I was able to study the automake files to offer a feeble attempt at a patch. The historical automake files provided me clues that the missing FAM support might be part of the original bug. So let's keep those files for a while. :)
Darrell
On Sunday 15 January 2012 02:44:08 pm Darrell Anderson wrote:
Try the attached patch. Ubuntu doesn't use gamin and I haven't noticed the problems you are experiencing with respect to files not showing up, but it is a good idea to enable this feature nevertheless.
Thanks Tim!
I see that I was close but still have much to learn. :)
The package now builds. I'll report in the bugzilla my testing results.
BTW, I think this is an example of why we should keep the automake files in the GIT tree even after converting to cmake, at least for a few more Trinity releases. Those files provide us a historical record. In this case, I was able to study the automake files to offer a feeble attempt at a patch. The historical automake files provided me clues that the missing FAM support might be part of the original bug. So let's keep those files for a while. :)
+1 on keeping autotool files
Does the current cmake files allow for make dist?
If not then please keep the autotool files so source tarballs can be made from the git repos.
On Sun, 15 Jan 2012 16:42:59 -0500 Baho Utot baho-utot@columbus.rr.com wrote:
On Sunday 15 January 2012 02:44:08 pm Darrell Anderson wrote:
Try the attached patch. Ubuntu doesn't use gamin and I haven't noticed the problems you are experiencing with respect to files not showing up, but it is a good idea to enable this feature nevertheless.
Thanks Tim!
I see that I was close but still have much to learn. :)
The package now builds. I'll report in the bugzilla my testing results.
BTW, I think this is an example of why we should keep the automake files in the GIT tree even after converting to cmake, at least for a few more Trinity releases. Those files provide us a historical record. In this case, I was able to study the automake files to offer a feeble attempt at a patch. The historical automake files provided me clues that the missing FAM support might be part of the original bug. So let's keep those files for a while. :)
+1 on keeping autotool files
Does the current cmake files allow for make dist?
There is no processing from VCS to tarballs like autoreconf when cmake is used, so git-archive should be enough.
If not then please keep the autotool files so source tarballs can be made from the git repos.
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 Sunday 15 January 2012 05:03:25 pm /dev/ammo42 wrote:
On Sun, 15 Jan 2012 16:42:59 -0500
Baho Utot baho-utot@columbus.rr.com wrote:
On Sunday 15 January 2012 02:44:08 pm Darrell Anderson wrote:
Try the attached patch. Ubuntu doesn't use gamin and I haven't noticed the problems you are experiencing with respect to files not showing up, but it is a good idea to enable this feature nevertheless.
Thanks Tim!
I see that I was close but still have much to learn. :)
The package now builds. I'll report in the bugzilla my testing results.
BTW, I think this is an example of why we should keep the automake files in the GIT tree even after converting to cmake, at least for a few more Trinity releases. Those files provide us a historical record. In this case, I was able to study the automake files to offer a feeble attempt at a patch. The historical automake files provided me clues that the missing FAM support might be part of the original bug. So let's keep those files for a while. :)
+1 on keeping autotool files
Does the current cmake files allow for make dist?
There is no processing from VCS to tarballs like autoreconf when cmake is used, so git-archive should be enough.
If not then please keep the autotool files so source tarballs can be made from the git repos.
maybe, Doing make dist from in the git repo to get a tarball almost always results in something usable and scriptable ;)
On Sunday 15 January 2012 05:03:25 pm /dev/ammo42 wrote:
On Sun, 15 Jan 2012 16:42:59 -0500
Baho Utot baho-utot@columbus.rr.com wrote:
On Sunday 15 January 2012 02:44:08 pm Darrell Anderson wrote:
Try the attached patch. Ubuntu doesn't use gamin and I haven't noticed the problems you are experiencing with respect to files not showing up, but it is a good idea to enable this feature nevertheless.
Thanks Tim!
I see that I was close but still have much to learn. :)
The package now builds. I'll report in the bugzilla my testing results.
BTW, I think this is an example of why we should keep the automake files in the GIT tree even after converting to cmake, at least for a few more Trinity releases. Those files provide us a historical record. In this case, I was able to study the automake files to offer a feeble attempt at a patch. The historical automake files provided me clues that the missing FAM support might be part of the original bug. So let's keep those files for a while. :)
+1 on keeping autotool files
Does the current cmake files allow for make dist?
There is no processing from VCS to tarballs like autoreconf when cmake is used, so git-archive should be enough.
If not then please keep the autotool files so source tarballs can be made from the git repos.
maybe, Doing make dist from in the git repo to get a tarball almost always results in something usable and scriptable ;)
See this page here: http://www.cmake.org/pipermail/cmake/2006-November/011874.html
Note that I have not tried this myself, as the Debian build system is quite different from manually building from source.
Tim
-
/dev/ammo42 -
Baho Utot -
Darrell Anderson -
Timothy Pearson