View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014506CMakeCMakepublic2013-10-23 02:532016-06-10 14:31
ReporterHarald Becker 
Assigned ToKitware Robot 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionmoved 
PlatformARMv7 iMX515 Cortex-A8OSLinuxOS VersionGentoo
Product VersionCMake 2.8.12 
Target VersionFixed in Version 
Summary0014506: cmake doesn't build on my ARM system, can't find external libraries
Descriptioncmake build fails always with a message, it can't find an external library. Usually this is ZLIB, but if I fiddle with FindZLIB (Insert name of Library), then it fails on next package, which is Curl. And so on.

The problem seams to be the cmake function Find_Library. It does not find external library names without adding explicit ".so" extension to list of searched name.

On my x86 Box this works correct, only on my ARM it neglects to build, so it may be a problem with setting up system names or detecting system.

This was also true in 2.8.10 and 2.8.11.1/2.
Steps To ReproduceGentoo standard build with native armv7a-hardfloat-linux-gnueapi toolchain.

Let me know what information you need for debugging. The ARM system is not my mail system, so I need to transfer information.
TagsNo tags attached.
Attached Filespatch file icon 0001-14506-Add-find_library-debug-output-try-1.patch [^] (2,449 bytes) 2013-10-25 16:57 [Show Content]

 Relationships

  Notes
(0034225)
Brad King (manager)
2013-10-23 08:38

The shared library suffix is set in the Modules/Platform/*.cmake files for the current platform. We need to see why .so is not set for this platform.

What is the output of "uname -s" on this system?

What command are you using to build CMake? Just "bootstrap"?
(0034237)
Harald Becker (reporter)
2013-10-24 21:11
edited on: 2013-10-25 03:28

Full build.log with failure is available at:
%%ftp://cmake@ralda.selfhost.eu/%% [^]
Password: cmake
File: cmake-build.tar.gz

Here is some more info about my system:

$ echo "'$( uname -s )'"
'Linux'

$ uname -a
Linux ecafe 2.6.35.4-ecafe5 0000048 PREEMPT Sun Jul 28 06:45:11 CEST 2013 armv7l ARMv7 Processor rev 5 (v7l) Hercules MX51 eCAFE 20110630 GNU/Linux

$ gcc --version
gcc (Gentoo 4.8.1-r1 p1.2, pie-0.5.7) 4.8.1

glibc version is 2.17

$ cat /proc/cpuinfo
Processor : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 159.90
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 5
Hardware : Hercules MX51 eCAFE 20110630

Edit Note: Sorry I hate those Browser fields, doing unexpected formatting :(

(0034242)
Brad King (manager)
2013-10-25 09:31

The find_library command should try the 'lib' prefix and '.so' suffix automatically on any system:

http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindLibraryCommand.cxx;hb=v2.8.12#l274 [^]
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeGenericSystem.cmake;hb=v2.8.12#l34 [^]

unless a Modules/Platform/$uname*.cmake file says otherwise. The Linux one does not.

What is the full path to libz.so that you expect it to find?

Please also try building by hand from the upstream source instead of the Gentoo package which applies a whole bunch of patches.
(0034248)
Harald Becker (reporter)
2013-10-25 15:26

> The find_library command should try the 'lib' prefix and '.so' suffix
> automatically on any system:... unless a Modules/Platform/$uname*.cmake
> file says otherwise. The Linux one does not.

This is why I have got confused. On my Linux x86 system (with compareable system installation) the build of cmake works fine. On the ARM it constantly fails with the same problem.

> What is the full path to libz.so that you expect it to find?

There is a /usr/lib/libz.so which is a GNU ld script containing the reference to /lib/libz.so.1 which is a symlink to /lib/libz.so.1.2.8
This is the same location as on my x86 system, and the standard location where any other package finds libz.

> Please also try building by hand from the upstream source instead of
> the Gentoo package which applies a whole bunch of patches.

I havn't done that yet, but will try this next. Meanwhile I grabbed the build directory, containing a dump of cmake variables. May be those are of value for debugging. Going to place this on my ftp server at ralda.selfhost.eu (user&pass = cmake), in file cmake-build2.tar.gz
(0034249)
Brad King (manager)
2013-10-25 15:43

I don't see anything wrong with the files in cmake-build2.tar.gz. Everything seems to work as expected. The system name and version is correct. The compiler identification is correct. The ABI is correct. The detected linker implicit search path is correct.

If you want to dig into the code the relevant find_library implementation is in Source/cmFindLibraryCommand.cxx probably somewhere around the cmFindLibraryHelper::CheckDirectoryForName method.
(0034250)
Harald Becker (reporter)
2013-10-25 16:36

> Everything seems to work as expected.

Yes, this is the confusing part :(

> If you want to dig into the code the relevant find_library

I already tried to do this, but I'm an old school C programmer, not C++. I roughly understand whats going on, but have trouble to understand the glory details of the code. Especially if things get done in a very complicated and not straight way (may be due to platform compatibility issues).

In addition I never dig into functionality of cmake, so I do not know how the things fit all together. Until I hit on the failing ARM, I only installed the cmake and Qt packages, without looking into build process.

Can you help me to insert debugging code to find the reason for this failure?
I know others have similar trouble, e.g. building cmake for Raspberry Pi, so I like to find and fix the failing part of the puzzle.
(0034251)
Brad King (manager)
2013-10-25 16:59

Re 0014506:0034250: Use 0001-14506-Add-find_library-debug-output-try-1.patch to add some debug statements. The output will be quite verbose and may show a lot about the files on your system so be careful with it if you have anything proprietary.
(0034252)
Harald Becker (reporter)
2013-10-25 17:40

Ok, got patch now, Thx. Extra thx for notice about private proprietary, but as this machine is non production there are only a few private files to be protected. May be I'm able to setup an ssh access for you, If that will help diagnosing the problem.

Currently trying pure upstream bootstrap (takes some time).
(0034253)
Harald Becker (reporter)
2013-10-25 18:56

Got some kind of success, using bare upstream version (no Gentoo patches, no parameter to bootstrap) ... but now it gets installed in wrong directories. So I'm now trying to use bootstrap parameters and narrow things down. As this is a slow machine it takes lot of time to build and test. So be patient, I'll give response on results.
(0034254)
Rolf Eike Beer (developer)
2013-10-25 19:03

If you already have bootstrapped a version you can skip bootstrapping on the next one. Also you can go to the build directory and simply write "cmake -D CMAKE_INSTALL_PREFIX=/opt/cmake . && make install" to change the install prefix. This will only rebuild what is neccessary.
(0034255)
Harald Becker (reporter)
2013-10-25 19:07

Thx Rolf, but I do not only want to quickly install a version, I want to find out where things break to get them fixed, so I stay on full but slow bootstrap.
(0034256)
Rolf Eike Beer (developer)
2013-10-25 19:17

No, you don't. Bootstrapping is just to get an initial cmake to be able to compile CMake. The thing you want to test is the CMake that is build afterwards. The intermediate CMake has no influence on how the latter one works. You just need to copy the file save the file InitialCacheFlags.cmake generated by a bootstrap run and can then configure the new CMake build using the old CMake:

mkdir /some/dir
cd /some/dir
old_cmake -C/path/to/InitialCacheFlags.cmake -D CMAKE_INSTALL_PREFIX=/some/where /path/to/cmake/sources
make
(0034257)
Harald Becker (reporter)
2013-10-25 19:33

Rolf, the problem is, the Gentoo build always does the full bootstrap, and this build crashes. So I now want to see at which difference between upstream cmake and Gentoo build breaks the thing. May be I stumbled on a Gentoo related bug, not cmake, but anyhow there is a bug in this build and it needs to be fixed. That is what I want do achieve, not a quick install of a cmake version. I do already have difference between bare upstream and Gentoo build, and it looks this difference arrive during bootstrap. So let's see what's the reason for this is.
(0034258)
Harald Becker (reporter)
2013-10-26 03:08
edited on: 2013-10-26 03:12

If I build cmake from upstream, and let Gentoo think it has installed cmake, I'm able to successfully build Qt libraries, but as soon as I try to build an application package the build aborts with a message like:

>>> Working in BUILD_DIR: "/var/portage/tmp/portage/sci-calculators/speedcrunch-0.10.1/work/speedcrunch-0.10.1_build"
cmake --no-warn-unused-cli -C /var/portage/tmp/portage/sci-calculators/speedcrunch-0.10.1/work/speedcrunch-0.10.1_build/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_INSTALL_DO_STRIP=OFF -DCMAKE_USER_MAKE_RULES_OVERRIDE=/var/portage/tmp/portage/sci-calculators/speedcrunch-0.10.1/work/speedcrunch-0.10.1_build/gentoo_rules.cmake /var/portage/tmp/portage/sci-calculators/speedcrunch-0.10.1/work/speedcrunch-0.10.1/src
Not searching for unused variables given on the command line.
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.

All application builds seem to complaining about CMAKE_ROOT, but I don't know how to set this in any way, or to do something different than "make install" for cmake. Is there any configuration which needs to be updated or any environment variable to be set?

Edit: The cmake Files are installed under /usr/share/cmake-2.8, the Module files under /usr/share/cmake-2.8/Modules. Docs at /usr/share/docs/..., man pages at /usr/share/man/..., binaries in /usr/bin.

(0034259)
Rolf Eike Beer (developer)
2013-10-26 04:58

Please put these files somewhere as I suspect them to contain something referencing to these variables:

/var/portage/tmp/portage/sci-calculators/speedcrunch-0.10.1/work/speedcrunch-0.10.1_build/gentoo_common_config.cmake
/var/portage/tmp/portage/sci-calculators/speedcrunch-0.10.1/work/speedcrunch-0.10.1_build/gentoo_rules.cmake
(0034260)
Rolf Eike Beer (developer)
2013-10-26 05:06

This looks highly suspicious, the value for that set is missing:

voyager ~ # cat /var/tmp/portage/dev-util/cmake-2.8.12/work/cmake-2.8.12_build/gentoo_common_config.cmake
SET (LIB_SUFFIX CACHE STRING "library path suffix" FORCE)
SET (CMAKE_INSTALL_LIBDIR lib CACHE PATH "Output directory for libraries")
(0034261)
Harald Becker (reporter)
2013-10-26 05:14

ecafe:speedcrunch-0.10.1_build> cat gentoo_common_config.cmake
SET (LIB_SUFFIX CACHE STRING "library path suffix" FORCE)
SET (CMAKE_INSTALL_LIBDIR lib CACHE PATH "Output directory for libraries")
SET (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" FORCE)
(0034262)
Harald Becker (reporter)
2013-10-26 05:14

ecafe:speedcrunch-0.10.1_build> cat gentoo_rules.cmake
SET (CMAKE_AR /usr/bin/armv7a-hardfloat-linux-gnueabi-ar CACHE FILEPATH "Archive manager" FORCE)
SET (CMAKE_ASM_COMPILE_OBJECT "<CMAKE_C_COMPILER> <DEFINES> -pipe -march=armv7-a -mcpu=cortex-a8 -O1 -fomit-frame-pointer <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "ASM compile command" FORCE)
SET (CMAKE_C_COMPILER /usr/bin/armv7a-hardfloat-linux-gnueabi-gcc CACHE FILEPATH "C compiler" FORCE)
SET (CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> <DEFINES> <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "C compile command" FORCE)
SET (CMAKE_CXX_COMPILER /usr/bin/armv7a-hardfloat-linux-gnueabi-g++ CACHE FILEPATH "C++ compiler" FORCE)
SET (CMAKE_CXX_COMPILE_OBJECT "<CMAKE_CXX_COMPILER> <DEFINES> <FLAGS> -o <OBJECT> -c <SOURCE>" CACHE STRING "C++ compile command" FORCE)
SET (CMAKE_RANLIB /usr/bin/armv7a-hardfloat-linux-gnueabi-ranlib CACHE FILEPATH "Archive index generator" FORCE)
SET (PKG_CONFIG_EXECUTABLE /usr/bin/armv7a-hardfloat-linux-gnueabi-pkg-config CACHE FILEPATH "pkg-config executable" FORCE)
(0034263)
Harald Becker (reporter)
2013-10-26 05:43

The only persistent difference I found between Gentoo build (without patches) and bare upstream build is the list of compiler flags / optimization? May be we hit a code generation problem in g++ on ARM.

Now trying with different CFLAG settings ...
(0034452)
Harald Becker (reporter)
2013-11-13 20:39

Problem solved. cmake need full read permission to the library directories. If this permission get blocked it doesn't find the libraries even if directory has execute right and libraries are fully readable. May be cmake shall give a hint if it can't find anything, saying something like: "does you have read permissions on lib directories?" ... this info would have saved me weeks of searching.
(0042401)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2013-10-23 02:53 Harald Becker New Issue
2013-10-23 08:38 Brad King Note Added: 0034225
2013-10-24 21:11 Harald Becker Note Added: 0034237
2013-10-24 21:16 Harald Becker Note Edited: 0034237
2013-10-25 03:28 Harald Becker Note Edited: 0034237
2013-10-25 09:31 Brad King Note Added: 0034242
2013-10-25 15:26 Harald Becker Note Added: 0034248
2013-10-25 15:43 Brad King Note Added: 0034249
2013-10-25 16:36 Harald Becker Note Added: 0034250
2013-10-25 16:57 Brad King File Added: 0001-14506-Add-find_library-debug-output-try-1.patch
2013-10-25 16:59 Brad King Note Added: 0034251
2013-10-25 17:40 Harald Becker Note Added: 0034252
2013-10-25 18:56 Harald Becker Note Added: 0034253
2013-10-25 19:03 Rolf Eike Beer Note Added: 0034254
2013-10-25 19:07 Harald Becker Note Added: 0034255
2013-10-25 19:17 Rolf Eike Beer Note Added: 0034256
2013-10-25 19:33 Harald Becker Note Added: 0034257
2013-10-26 03:08 Harald Becker Note Added: 0034258
2013-10-26 03:12 Harald Becker Note Edited: 0034258
2013-10-26 04:58 Rolf Eike Beer Note Added: 0034259
2013-10-26 05:06 Rolf Eike Beer Note Added: 0034260
2013-10-26 05:14 Harald Becker Note Added: 0034261
2013-10-26 05:14 Harald Becker Note Added: 0034262
2013-10-26 05:43 Harald Becker Note Added: 0034263
2013-11-13 20:39 Harald Becker Note Added: 0034452
2016-06-10 14:29 Kitware Robot Note Added: 0042401
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team