Bug 872

There is also a cmake error that fails to find subversion libraries, even though they are installed in /usr/lib:

-- checking for 'ktnef'
--   ok, found import file
-- checking for 'libkcal'
--   ok, found import file
-- checking for one of the modules 'apr-1'
-- Looking for svn_pool_create_ex in svn_client-1
-- Looking for svn_pool_create_ex in svn_client-1 - not found
CMake Error at cmake/modules/TDEMacros.cmake:23 (message):
  #################################################

   svn_client-1 library was not found on your system.
   Subversion is installed?
   Try to set SVN_LIBRARY_DIR to subversion library directory.

  #################################################
Call Stack (most recent call first):
  kioslave/svn/ConfigureChecks.cmake:27 (tde_message_fatal)
  kioslave/svn/CMakeLists.txt:12 (include)

22:35 nirvana:/mnt/nv1/home/chroot/david> l1 /usr/lib/libsvn_client*
/usr/lib/libsvn_client-1.a
/usr/lib/libsvn_client-1.so
/usr/lib/libsvn_client-1.so.0
/usr/lib/libsvn_client-1.so.0.0.0

Updated description to clarify the problem is with the cmake port and not with automake. tdesdk builds w/o error with automake.

I have been building tdesdk with automake. Today I tried building with cmake and received the following failure, which different from that of the original report (that bug probably still exists but I don't get that far with the new failure):

=====================================================================
make -f kstartperf/CMakeFiles/kstartperf.dir/build.make kstartperf/CMakeFiles/kstartperf.dir/depend
make[2]: Entering directory `/dev/shm/tdesdk.build'
cd /dev/shm/tdesdk.build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /dev/shm/tdesdk /dev/shm/tdesdk/kstartperf /dev/shm/tdesdk.build /dev/shm/tdesdk.build/kstartperf /dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf.dir/DependInfo.cmake --color=
Dependee "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf.dir/DependInfo.cmake" is newer than depender "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf.dir/depend.internal".
Dependee "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf.dir/depend.internal".
Scanning dependencies of target kstartperf
make[2]: Leaving directory `/dev/shm/tdesdk.build'
make -f kstartperf/CMakeFiles/kstartperf.dir/build.make kstartperf/CMakeFiles/kstartperf.dir/build
make[2]: Entering directory `/dev/shm/tdesdk.build'
/usr/bin/cmake -E cmake_progress_report /dev/shm/tdesdk.build/CMakeFiles 
[ 52%] Building CXX object kstartperf/CMakeFiles/kstartperf.dir/kstartperf.cpp.o
cd /dev/shm/tdesdk.build/kstartperf && /usr/bin/c++   -DHAVE_CONFIG_H -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 -I/opt/trinity/include -I/usr/include/tqt   -o CMakeFiles/kstartperf.dir/kstartperf.cpp.o -c /dev/shm/tdesdk/kstartperf/kstartperf.cpp
Linking CXX executable kstartperf
cd /dev/shm/tdesdk.build/kstartperf && /usr/bin/cmake -E cmake_link_script CMakeFiles/kstartperf.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/kstartperf.dir/kstartperf.cpp.o  -o kstartperf -rdynamic -L/opt/trinity/lib /opt/trinity/lib/libtdecore.so.4.2.0 /opt/trinity/lib/libDCOP.so.4.2.0 /opt/trinity/lib/libtdefx.so.4.2.0 -ltqt -ltqt-mt -lXrender -lX11 -lz -lidn -lXcomposite -lXfixes -lICE -lSM -ludev -lgamin-1 -Wl,-rpath,/opt/trinity/lib: 
make[2]: Leaving directory `/dev/shm/tdesdk.build'
/usr/bin/cmake -E cmake_progress_report /dev/shm/tdesdk.build/CMakeFiles 
[ 52%] Built target kstartperf
make -f kstartperf/CMakeFiles/kstartperf-shared.dir/build.make kstartperf/CMakeFiles/kstartperf-shared.dir/depend
make[2]: Entering directory `/dev/shm/tdesdk.build'
cd /dev/shm/tdesdk.build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /dev/shm/tdesdk /dev/shm/tdesdk/kstartperf /dev/shm/tdesdk.build /dev/shm/tdesdk.build/kstartperf /dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf-shared.dir/DependInfo.cmake --color=
Dependee "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf-shared.dir/DependInfo.cmake" is newer than depender "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf-shared.dir/depend.internal".
Dependee "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/dev/shm/tdesdk.build/kstartperf/CMakeFiles/kstartperf-shared.dir/depend.internal".
Scanning dependencies of target kstartperf-shared
make[2]: Leaving directory `/dev/shm/tdesdk.build'
make -f kstartperf/CMakeFiles/kstartperf-shared.dir/build.make kstartperf/CMakeFiles/kstartperf-shared.dir/build
make[2]: Entering directory `/dev/shm/tdesdk.build'
/usr/bin/cmake -E cmake_progress_report /dev/shm/tdesdk.build/CMakeFiles 
[ 52%] Building C object kstartperf/CMakeFiles/kstartperf-shared.dir/libkstartperf.c.o
cd /dev/shm/tdesdk.build/kstartperf && /usr/bin/gcc  -Dkstartperf_shared_EXPORTS -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -fPIC -I/opt/trinity/include -I/usr/include/tqt   -o CMakeFiles/kstartperf-shared.dir/libkstartperf.c.o   -c /dev/shm/tdesdk/kstartperf/libkstartperf.c
Linking C shared library libkstartperf.so
cd /dev/shm/tdesdk.build/kstartperf && /usr/bin/cmake -E cmake_link_script CMakeFiles/kstartperf-shared.dir/link.txt --verbose=1
/usr/bin/gcc  -fPIC -O2 -march=i486 -mtune=i686 -Wl,--no-undefined -shared -Wl,-soname,libkstartperf.so.1 -o libkstartperf.so.1.0.0 CMakeFiles/kstartperf-shared.dir/libkstartperf.c.o -L/opt/trinity/lib -lldl -Wl,-rpath,/opt/trinity/lib: 
/usr/lib/gcc/i486-slackware-linux/4.4.4/../../../../i486-slackware-linux/bin/ld: cannot find -lldl
collect2: ld returned 1 exit status
make[2]: *** [kstartperf/libkstartperf.so.1.0.0] Error 1
make[2]: Leaving directory `/dev/shm/tdesdk.build'
make[1]: *** [kstartperf/CMakeFiles/kstartperf-shared.dir/all] Error 2
make[1]: Leaving directory `/dev/shm/tdesdk.build'
make: *** [all] Error 2
=====================================================================

The original bug should be fixed (but is untested) as of GIT hash 982d76c.

Note that at a minimum you will need to rebuild/reinstall tqtinterface before attempting another tdesdk build due to a new file in that module.

(In reply to comment #1)
> There is also a cmake error that fails to find subversion libraries, even
> though they are installed in /usr/lib:
> 
> -- checking for 'ktnef'
> --   ok, found import file
> -- checking for 'libkcal'
> --   ok, found import file
> -- checking for one of the modules 'apr-1'
> -- Looking for svn_pool_create_ex in svn_client-1
> -- Looking for svn_pool_create_ex in svn_client-1 - not found
> CMake Error at cmake/modules/TDEMacros.cmake:23 (message):
>   #################################################
> 
>    svn_client-1 library was not found on your system.
>    Subversion is installed?
>    Try to set SVN_LIBRARY_DIR to subversion library directory.
> 
>   #################################################
> Call Stack (most recent call first):
>   kioslave/svn/ConfigureChecks.cmake:27 (tde_message_fatal)
>   kioslave/svn/CMakeLists.txt:12 (include)
> 
> 22:35 nirvana:/mnt/nv1/home/chroot/david> l1 /usr/lib/libsvn_client*
> /usr/lib/libsvn_client-1.a
> /usr/lib/libsvn_client-1.so
> /usr/lib/libsvn_client-1.so.0
> /usr/lib/libsvn_client-1.so.0.0.0

Which library file on your system contains the symbol svn_pool_create_ex?

That comment was filed by David, but how do I find symbols?

(In reply to comment #6)
> That comment was filed by David, but how do I find symbols?

Usually I just do an exact text search for the symbol name in the library directory and see which .so files contain the string.

I suspect that the symbol was moved to a different library on David's system, hence my request.

Part One:

Regarding the latest patches, I received the following tdesdk build failure message:

tmoc is not found!
tqtqui is correctly installed?

Looking at tdesdk/cmake/modules/FindTQtQUI.cmake, I see the following:

pkg-config tqtqui --variable=tmoc_executable

My understanding is cmake/modules is a sym link in all modules at the master repository and therefore, all modules are the same when copied locally. Therefore after you patched things earlier today for the same errors, I performed a full resync of my local GIT tree, which included tdesdk.

If the FindTQtQUI.cmake command is correct, then the problem is no tmoc_executable variable defined in the new tqtqui.pc file.

As a test, I copied and pasted the following from tqt.pc to tqtqui.pc:

tmoc_executable=/usr/bin/tmoc
moc_executable=/opt/trinity/bin/moc
uic_executable=/opt/trinity/bin/uic

That got me past the build error just described.

I leave to you how tqtqui.pc should be properly updated. I presume that rebuilding tdesdk requires rebuilding tqtinterface after you update tqtqui.pc.

P.S. All of the core and main suite packages built without error. tdesdk is the first failure today after your tmoc patches.

Part Two:

I can't actually test the latest patches because the build fails before the kuiviewer component is built. Refer to Comment 3 for the build log.

Actually, I get past the failure in Comment 3 when I use -DBUILD_KSTARTPERF=OFF. Sadly, I then still experience the original build failure reported here. I again bypass that error using -DBUILD_KUIVIEWER=OFF.

Building with automake is successful with no build errors for any components.

At this point I can build with cmake only with the following:

WITH_KUIVIEWER=OFF (Original report)
WITH_KSTARTPERF=OFF (Comment 3)

I have not tried building against Qt3 (haven't tried that in many weeks). Only TQt3.

I hope this information helps.

Spurious tmoc check removed in GIT hash 07921f2.

kstartperf build failure should be fixed in GIT hash 3950c6b.

At this point, we just need David's input on the svn library problem, (provided that the patches I just pushed actually work as intended. ;-)

The latest cmake testing:

-DBUILD_KSTARTPERF=ON
-DBUILD_KUIVIEWER=OFF

tdesdk builds without errors. The kstartperf error appears resolved. Thank you!

-DBUILD_KSTARTPERF=ON
-DBUILD_KUIVIEWER=ON

tdesdk fails with the original build error:

/usr/lib/gcc/i486-slackware-linux/4.4.4/../../../../i486-slackware-linux/bin/ld: cannot find -lqui

All other TDE packages built without error. This was a clean full build with my local repo updated this morning after the latest patches were posted.

As before, no errors when building with automake.

Darn, it looks like I missed a hardcoded 'qui' last time.  This should be fixed in GIT hash 3f313ef.

Please make sure that libkuiviewerpart and quithumbnail work properly when built from CMake--even if the build succeeds, the affected applications may fail to start if the linking is not 100% correct.  If tdesdk builds with CMake and the affected applications do start properly then feel free to close this report. :-)

No problem. :-)

Local GIT updated, tdesdk rebuilt without error using cmake. The package contains kstartperf and kuiviewer. Thank you!

How do I test libkuiviewerpart and quithumbnail for usability? I'm unfamiliar with both.

I opened kuiviewer from the TDE menu. The app opens but that is as far as I get. What next?

I don't see anything in the menu related to quithumbnail.

kstartperf runs fine from konsole without incident .

(In reply to comment #13)
> How do I test libkuiviewerpart and quithumbnail for usability? I'm unfamiliar
> with both.
> 
> I opened kuiviewer from the TDE menu. The app opens but that is as far as I
> get. What next?

That is a sufficient test for the entire patch.

Thank you!

I'm back to building with automake. :-(

The latest cmake build failure:

-- Looking for svn_pool_create_ex in svn_client-1
-- Looking for svn_pool_create_ex in svn_client-1 - not found
CMake Error at cmake/modules/TDEMacros.cmake:23 (message):
  #################################################

   svn_client-1 library was not found on your system.
   Subversion is installed?
   Try to set SVN_LIBRARY_DIR to subversion library directory.

  #################################################
Call Stack (most recent call first):
  kioslave/svn/ConfigureChecks.cmake:27 (tde_message_fatal)
  kioslave/svn/CMakeLists.txt:12 (include)


The configure test is from tdesdk/kioslave/svn/ConfigureChecks.cmake.

David ran into this failure in March (http://trinity-devel.pearsoncomputing.net/?0::6654).

tdesdk builds without this specific failure using cmake on Slackware 13.1 and 13.37, both 32 and 64-bit. Those releases use subversion 1.6.16.

Slackware Current bumped the subversion package to version 1.7.5. I suspect this is the cause of the failure.

Looking at the packages between the two, the libsvn_client-1 lib files are installed in the same location, /usr/lib/. All header files are installed in the same location, /usr/include/subversion-1/.

Because Slackware Current is the testing branch for the next release, there is a possibility the package is not built correctly, but because David experienced this failure in March, I am discounting that possibility. Of course, there could be an upstream problem with the way the package builds that would be common downstream to all packagers.

tdesdk builds without incident using automake and as far as I can tell, all svn support was built.

At this point looks like we need to modify tdesdk/kioslave/svn/ConfigureChecks.cmake.

Any ideas?

I need an answer to my original Comment #7 to proceed.

Using 'grep -rla svn_pool_create_ex /usr/lib', the following files appear to have that string in the file:

/usr/lib/libsvn_ra_local-1.so.0.0.0
/usr/lib/libsvn_repos-1.so.0.0.0
/usr/lib/libsvn_delta-1.so
/usr/lib/libsvn_subr-1.so
/usr/lib/libsvn_fs_base-1.so
/usr/lib/libsvn_swig_ruby-1.so.0
/usr/lib/libsvn_ra-1.so.0.0.0
/usr/lib/libsvn_fs_fs-1.so.0
/usr/lib/libsvn_diff-1.so
/usr/lib/libsvn_client-1.so.0.0.0
/usr/lib/libsvn_ra_neon-1.so
/usr/lib/libsvn_delta-1.so.0.0.0
/usr/lib/libsvn_subr-1.so.0.0.0
/usr/lib/libsvn_wc-1.so.0.0.0
/usr/lib/libsvn_swig_ruby-1.so.0.0.0
/usr/lib/libsvn_ra_neon-1.so.0
/usr/lib/libsvn_wc-1.so
/usr/lib/libsvn_swig_py-1.so.0.0.0
/usr/lib/libsvn_diff-1.so.0.0.0
/usr/lib/libsvn_ra_local-1.so.0
/usr/lib/libsvn_ra_neon-1.so.0.0.0
/usr/lib/libsvn_wc-1.so.0
/usr/lib/libsvn_swig_ruby-1.so/usr/lib/libsvn_repos-1.so.0
/usr/lib/libsvn_swig_py-1.so.0
/usr/lib/libsvn_diff-1.so.0
/usr/lib/libsvn_delta-1.so.0
/usr/lib/libsvn_fs_base-1.so.0
/usr/lib/libsvn_ra_svn-1.so
/usr/lib/libsvn_repos-1.so
/usr/lib/libsvn_client-1.so.0
/usr/lib/libsvn_fs_base-1.so.0.0.0
/usr/lib/libsvn_swig_py-1.so
/usr/lib/httpd/modules/mod_dav_svn.so
/usr/lib/libsvn_fs-1.so.0
/usr/lib/libsvn_ra-1.so
/usr/lib/libsvn_ra_local-1.so
/usr/lib/libsvn_subr-1.so.0
/usr/lib/libsvn_ra_svn-1.so.0
/usr/lib/libsvn_ra-1.so.0
/usr/lib/kde3/kio_kdevsvn.so
/usr/lib/kde3/kio_svn.so
/usr/lib/libsvn_fs_fs-1.so
/usr/lib/libsvn_fs-1.so
/usr/lib/python2.6/site-packages/libsvn/_core.so
/usr/lib/ruby/site_ruby/1.9.1/i486-linux/svn/ext/core.so
/usr/lib/libsvn_client-1.so
/usr/lib/libsvn_fs-1.so.0.0.0
/usr/lib/libsvn_ra_svn-1.so.0.0.0
/usr/lib/perl5/vendor_perl/5.10.1/i486-linux-thread-multi/auto/SVN/_Core/_Core.so
/usr/lib/libsvn_fs_fs-1.so.0.0.0

(In reply to comment #18)
> Using 'grep -rla svn_pool_create_ex /usr/lib', the following files appear to
> have that string in the file:
> 
> /usr/lib/libsvn_client-1.so.0

Hmm, that looks OK.  Can you attach your CMakeOutput.txt and CMakeErrors.txt files from an unsuccessful build attempt?

Thanks!

CMakeOutput.txt and CMakeErrors.txt do not exist. I suspect the build fails too early?

Created attachment 694 [details]
tdesdk cmake files from failed build with cmake

I found the files. Different names.

Created attachment 695 [details]
Enable detection of svn_pool_create_ex in libsvn_subr-1

Looks like the symbol svn_pool_create_ex was moved to libsvn_subr-1.so

Try the attached patch; if it fails please attache the same files again from the new build.

Created attachment 696 [details]
New cmake test logs

Failed again. I added a text message to the patch to ensure the patch was working:

message( STATUS "svn_client-1 library not found. Checking svn_subr-1.")

In the error log I notice only one message about "Determining if the function svn_pool_create_ex exists in the svn_client-1 failed with the following output:"

I expected two such messages because the patch has two tests. As there is only one, that implies the second test succeeded. The error log confirms this:

'svn_pool_create_ex' is defined in DSO /usr/lib/libsvn_subr-1.so.0 so try adding it to the linker command line

The next line in the log:

/usr/lib/libsvn_subr-1.so.0: could not read symbols: Invalid operation

Created attachment 697 [details]
Enable detection of svn_pool_create_ex in libsvn_subr-1

Try this patch; CMake doesn't clear the variable from the first failure, so I now explicitly clear it before the second test.

Nope. :-( Same failure message.

OK, it looks like I need to work on this on a local system.

What is the exact libsvn version that you have installed on your machine?

The subversion package versions that don't fail are 1.6.16. (Slackware 13.1 and 13.37)

The subversion version that fails is 1.7.5. (Slackware Current --- soon to be Slackware 14)

Possibly the 1.7.5 version failures are caused by other factors, such as we have seen with the gcc 4.7.1 obstacles. If that is possible I could try to build a 1.6.16 package for Slackware Current. Or conversely, build a 1.7.5 package for the Slackware releases that don't see the build failure.

Why is this always so much work?

> Why is this always so much work?

Because FOSS is constantly changing; sometimes for the better, oftentimes just for the sake of change, and many times for the worse.

This bug is resolved in GIT hash 572169a.

Ya think? Looks like I have a package built with cmake with subversion 1.75!

This patches solved FTBFS on openSUSE.
It should go in 3.5.13-SRU.