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
-- 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.
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.
– 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!
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
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.
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…
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.
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.
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.
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.