need cmake 3.1 or higher in opensuse 13.2, yast only has 3.0

Hello

I need to build an app I downloaded on bitbucket and it uses cmake. I am getting an error that cmake 3.1 or higher is required but yast only has 3.0 available.

Is there some way to install a more current version of cmake?

software.opensuse only lists 3.0.2 for opensuse 13.2

https://software.opensuse.org/package/cmake

Suggestions?

LMHmedchem

https://software.opensuse.org/package/cmake

Klick on openSUSE13.2, then on show unstable Versions.
I would prefer the Version from devle:tools:building or devel:tools:compiler.

Thanks, that worked just fine. The install went smoothly and I was able to build the application.

I never noticed the unstable versions link there before, good to know.

Thanks again,

LMHmedchem

I now have another problem, I have no idea what to do next. I ran cmake with,

cmake -DCMAKE_CXX_COMPILER=clang -DCMAKE_BUILD_TYPE=Release  .. 

and got the following output,

-- The C compiler identification is GNU 4.8.3
-- The CXX compiler identification is Clang 3.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang
-- Check for working CXX compiler: /usr/bin/clang -- works                                                
-- Detecting CXX compiler ABI info                                                                        
-- Detecting CXX compiler ABI info - done                                                                 
-- Detecting CXX compile features                                                                         
-- Detecting CXX compile features - done
-- Performing Test COMPILER_SUPPORTS_LIBCXX
-- Performing Test COMPILER_SUPPORTS_LIBCXX - Success
-- Performing Test COMPILER_SUPPORTS_CXX1Z
-- Performing Test COMPILER_SUPPORTS_CXX1Z - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user1/ATomilov_quickhull/trunk/build

I am not sure what to do next. I guess I need to run some kind of install command. I don’t see the compiled and built application in any of the files that cmake generated with the above command. I have spent more than an hour reading through the cmake documentation and I don’t see any examples of how you actually use cmake to build and install a program. There is allot on how to write the CMakeLists.txt file, but nothing for end users who are supposed to install a project set up to use cmake.

LMHmedchem

This is the project I am trying to build if that matters,

https://github.com/tomilov/quickhull

I can’t find any .o object files anywhere in the CMakeFiles directory, so it’s hard to imagine that anything got compiled even though the script completed.

This may be a topic for the applications forum now that I have the correct version of CMake and Clang installed. Let me know if I should post this elsewhere.

LMHmedchem

On Fri 29 Jul 2016 05:26:02 PM CDT, LMHmedchem wrote:

I now have another problem, I have no idea what to do next. I ran cmake
with,

Code:

cmake -DCMAKE_CXX_COMPILER=clang -DCMAKE_BUILD_TYPE=Release …

and got the following output,

Code:

– The C compiler identification is GNU 4.8.3
– The CXX compiler identification is Clang 3.5.0
– Check for working C compiler: /usr/bin/cc
– Check for working C compiler: /usr/bin/cc – works
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Detecting C compile features
– Detecting C compile features - done
– Check for working CXX compiler: /usr/bin/clang
– Check for working CXX compiler: /usr/bin/clang –
works – Detecting CXX compiler ABI
info – Detecting CXX compiler ABI info -
done – Detecting CXX compile
features – Detecting CXX compile features - done
– Performing Test COMPILER_SUPPORTS_LIBCXX
– Performing Test COMPILER_SUPPORTS_LIBCXX - Success
– Performing Test COMPILER_SUPPORTS_CXX1Z
– Performing Test COMPILER_SUPPORTS_CXX1Z - Success
– Configuring done
– Generating done
– Build files have been written
to: /home/user1/ATomilov_quickhull/trunk/build --------------------

I am not sure what to do next. I guess I need to run some kind of
install command. I don’t see the compiled and built application in any
of the files that cmake generated with the above command. I have spent
more than an hour reading through the cmake documentation and I don’t
see any examples of how you actually use cmake to build and install a
program. There is allot on how to write the CMakeLists.txt file, but
nothing for end users who are supposed to install a project set up to
use cmake.

LMHmedchem

Hi
You need to run make, then if all good, test as your user (as in try
the binary), then as root user make install in the build directory.


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Hi
And it needs to be clang++ :wink:

https://build.opensuse.org/package/show/home:malcolmlewis:TESTING/quickhull

This is the ls from my trunk directory,

/home/ATomilov_quickhull/trunk
$ ls -R

/build  /CMakeLists.txt  /include  notes.txt  README.md  /src  /test

./build:
cmake_install.cmake  CMakeCache.txt  CMakeFiles  Makefile

./build/CMakeFiles:
3.6.1                            feature_tests.bin  progress.marks
cmake.check_cache                feature_tests.c    qh.dir
CMakeDirectoryInformation.cmake  feature_tests.cxx  quickhull.dir
CMakeOutput.log                  Makefile.cmake     TargetDirectories.txt
CMakeTmp                         Makefile2

./build/CMakeFiles/3.6.1:
CMakeCCompiler.cmake               CMakeSystem.cmake
CMakeCXXCompiler.cmake             CompilerIdC
CMakeDetermineCompilerABI_C.bin    CompilerIdCXX
CMakeDetermineCompilerABI_CXX.bin

./build/CMakeFiles/3.6.1/CompilerIdC:
a.out  CMakeCCompilerId.c

./build/CMakeFiles/3.6.1/CompilerIdCXX:
a.out  CMakeCXXCompilerId.cpp

./build/CMakeFiles/CMakeTmp:

./build/CMakeFiles/qh.dir:
build.make         depend.make       flags.make  progress.make
cmake_clean.cmake  DependInfo.cmake  link.txt    src

./build/CMakeFiles/qh.dir/src:

./build/CMakeFiles/quickhull.dir:
build.make         depend.make       flags.make  progress.make
cmake_clean.cmake  DependInfo.cmake  link.txt    src

./build/CMakeFiles/quickhull.dir/src:

./include:
quickhull.hpp

./src:
quickhull.cpp  randombox.cpp  simple_use.cpp

./test:
bad_samples.bash  bad_samples_v2.sh  ray_plane_intersect.m
bad_samples.txt   qprof.sh           samples

./test/samples:
crush0.txt  float_complanar_facets0.txt  nf5.txt

From where do I run make? The Makefile is in ./build, so do I,

$ cd ./build
$ make -f Makefile all

or is this not gnu make that I am running?

I would assume that cmake set up the makefile to use clang because I ran cmake with,

-DCMAKE_CXX_COMPILER=clang

Does that address the clang issue or do I have to add something to the call to make?

I’m not in linux at the moment so I would like to get the instructions clear before I switch over.

LMHmedchem

Hi
Yes, in your case the build directory and run the command make (it is the GNU make…), no need for the additional command options with make…

You need to re run cmake using clang++

My understanding was the there was no difference between clang and clang++, meaning that both are just symlinks to the same clang binary. Anyway, I reconfigured using clang++ and did make. The app works in the logical sense but I am getting a segfault. I think this is just the app not set up to work on input the size of what I am using.

I am trying to debug at the moment to see if there is something that can be done to fix this. I am running into a problem in that I have never used gdb with a program that takes its input from stdin. The app is run like,

cat PCA_46-inputs.txt | ./quickhull

I tried running gdb like,

gdb $(cat PCA_46-inputs.txt | ./quickhull)

This runs, but I don’t know what to do when I get to the gdb prompt. I built the app with -DCMAKE_BUILD_TYPE=Debug and I understand that this is how you use cmake to set the flags for gdb but I’m not sure

Any advice on what to do next?

LMHmedchem

Hi
Try building from the released version rather than trunk?

Is it possible to provide PCA_46-inputs.txt so I can test?

Sorry, I’m not sure what you mean by this. If you mean my directory name, trunk is just the name I usually give to my project directories (a holdover from svn). If I extract the project as downloaded, the name of the project folder is /tomilov-quickhull-7faf277d6cc2. I have run cmake with -DCMAKE_BUILD_TYPE=Release and -DCMAKE_BUILD_TYPE=Debug and both give me the segfault. I went to the Debug version when I tried to run gdb.

For some reason, I am not able to attach files in this forum. I think this is odd since I have been a member here for quite a while. The 15000 character limit prevents me from including it in the text of a post. I will put the file on the net somewhere else for you to download.

LMHmedchem

Here is the link to the input file,

http://wikisend.com/download/293126/PCA_46-inputs.txt

Thank you very much for the help by the way, I wouldn’t have got to first base with this thing without some very concrete help from a number of kind folks…

LMHmedchem

Hi
So on both Tumbleweed and Leap 42.1 I get the following;


quickhull < PCA_46-inputs.txt
input file: stdin
dimensionality of input is 46
rbox command line:
input points count = 1955
epsilon = 0
simplex time = 160018us

Then it just sits there banging on one core, is this the expected output or should there be more?

The output should be a list of vertex numbers. Other versions of quickhull will output other information, such as the coordinates of the vertex numbers that are found. I didn’t really see a list of arguments in a quick look at the code so I don’t know what options there are as far as output goes.

In short, the input file is essentially a list of vectors where each vector is a set of coordinates in n-space. In this input file, there are 46 columns, so there are 46 dimensions to the space. There are also 1955 rows (or vertices). The first row of input gives the dimensions and the second gives the number of data rows. The remaining rows are the coordinates of each vertex.

The qhull algorithm is looking for the convex hull, which is the sub-set of vertices that define the minimal volume that encompass all points in the data set. If this was in 2-space, the points would be in a blob on the graph and you would trace a line around the outside of the blob connecting all the points on the outer edge in such a way as to create the smallest area that contains all the points. This is obviously more complex in 46 dimensions than in two.

The wiki page on quickhull gives a nice explanation if you have a minute or so to check it out.
https://en.wikipedia.org/wiki/Quickhull

I get the same output as you describe, but eventually I get a segfault. My guess is that the app is just running flat out of memory because it wasn’t designed to work on a dataset with this many dimensions or rows. The original qhull app, that is included in the math section of most linux distros fails on this dataset much more quickly. The reason I built this is that I read a blog by the author that said this version was created to work in high-dimensional space. The fact that it runs for longer before it borks may indicate that it is somewhat better but it still isn’t working for me.

Does the app eventually segfault if you let it run for long enough?

I really need to find the convex hull for this set, and for some others of similar size. I am hoping that the segfault can be cleared up by allocating more memory or something like that. According to the system reporting, I am not running out of memory from the hardware point of view. There could also be something like an out of bounds issue, etc. That is why I was trying to get gdb working so I could see where exactly in the code this was failing.

If it isn’t giving you a segfault, maybe you could just let it run and see if it finishes. Eventually there should be output to stdout giving a list of vertex numbers.

LMHmedchem

monitor memory use while running by using top in a different konsole

Hi
Yes, it finally segfaults after about one hour, it is using memory, gets to about 13% before it segfaults. I started it via gdb and see how it goes in an hour or so.

If you want to run via gdb, then;


gdb quickhull
run < PCA_46-inputs.txt

Hi
Here is the debug info;


(gdb) run < PCA_46-inputs.txt
Starting program: /usr/bin/quickhull < PCA_46-inputs.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
input file: stdin
dimensionality of input is 46
rbox command line:
input points count = 1955
epsilon = 0
simplex time = 423152us

Program received signal SIGSEGV, Segmentation fault.
0x000000000041e2c5 in std::__1::__split_buffer<quick_hull<std::__1::__forward_list_iterator<std::__1::__forward_list_node<std::__1::forward_list<double, std::__1::allocator<double> >, void*>*>, double>::facet*, std::__1::allocator<quick_hull<std::__1::__forward_list_iterator<std::__1::__forward_list_node<std::__1::forward_list<double, std::__1::allocator<double> >, void*>*>, double>::facet*> >::push_back(quick_hull<std::__1::__forward_list_iterator<std::__1::__forward_list_node<std::__1::forward_list<double, std::__1::allocator<double> >, void*>*>, double>::facet*&&) (this=0x7fffffffdd50, 
    __x=<unknown type in /usr/lib/debug/usr/bin/quickhull.debug, CU 0x15b, DIE 0x54748>) at /usr/include/c++/v1/__split_buffer:565
565        if (__end_ == __end_cap())

On Sun 31 Jul 2016 02:46:01 PM CDT, malcolmlewis wrote:

Hi
Here is the debug info;

Code:

(gdb) run < PCA_46-inputs.txt
Starting program: /usr/bin/quickhull < PCA_46-inputs.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib64/libthread_db.so.1”.
input file: stdin
dimensionality of input is 46
rbox command line:
input points count = 1955
epsilon = 0
simplex time = 423152us

Program received signal SIGSEGV, Segmentation fault.
0x000000000041e2c5 in
std::__1::__split_buffer<quick_hull<std::__1::__forward_list_iterator<std::__1::__forward_list_node<std::__1::forward_list<double,
std::__1::allocator<double> >, void*>>, double>::facet,
std::__1::allocator<quick_hull<std::__1::__forward_list_iterator<std::__1::__forward_list_node<std::__1::forward_list<double,
std::__1::allocator<double> >, void*>>, double>::facet>
>::push_back(quick_hull<std::__1::__forward_list_iterator<std::__1::__forward_list_node<std::__1::forward_list<double,
>std::__1::allocator<double> >, void*>>, double>::facet&&)
>(this=0x7fffffffdd50, __x=<unknown type
>in /usr/lib/debug/usr/bin/quickhull.debug, CU 0x15b, DIE 0x54748>)
>at /usr/include/c++/v1/__split_buffer:565 565 if (_end ==
>__end_cap()) --------------------

Hi
And for qh;


(gdb) run < PCA_46-inputs.txt
Starting program: /usr/bin/qh < PCA_46-inputs.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
dimensionality of input is 46
rbox command line:
input points count = 1955
epsilon = 2.22045e-16
simplex time = 416578us

Program received signal SIGSEGV, Segmentation fault.
0x000000000042dd8f in std::__1::__hash_table<unsigned long,
std::__1::hash<unsigned long>, std::__1::equal_to<unsigned long>,
std::__1::allocator<unsigned long> >::__construct_node (this=<error
reading variable: Cannot access memory at address 0x7fffff7fecf8>,
__v=<error reading variable: Cannot access memory at address
0x7fffff7fecf0>, __hash=<error reading variable: Cannot access memory
0x7fffff7fecf0>at address 0x7fffff7fece8>)
0x7fffff7fecf0>at /usr/include/c++/v1/__hash_table:2088 2088	{


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Boy this looks like it’s going to be fun to try and resolve. It looks like these are c++ header files where the errors are happening. I don’t see a line number in the quickhull src code.

It looks like qh is called from quickhull and that there is an issue trying to read from a hash table. Cannot access memory is more or less what I was expecting to find. The question is where the algorithm is going wrong since it is not running out of physical memory. I wonder if the hash table has a declared size that is being exceeded by this input and the code is not excepted to realize that it is going out of bounds.

LMHmedchem