build failure on RedHat 6.4

373 views
Skip to first unread message

clyde

unread,
Mar 9, 2015, 12:07:30 PM3/9/15
to ope...@googlegroups.com
I copied OpenVSP-master.zip from github. I unzipped it and began to follow the instructions.
> gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)

> swig -version

SWIG Version 1.3.40

Compiled with g++ [x86_64-redhat-linux-gnu]

I had installed previous versions. I was happy to see that some of what I had to do before was eliminated, ie I would not have to install opennurbs or fltk, and the system had a sufficiently up-to-date version of cmake. So I tried to just follow the README instructions.

> python --version
Python 2.7.6
> cmake --version
cmake version 2.8.12.2
>doxygen -help
Doxygen version 1.6.1
...
 So it looks as if I have the required tools as per the README, although it doesn't specify versions.

> mkdir build
> cd build
> cmake ../src-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- 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
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Doxygen: /usr/bin/doxygen (found version "1.6.1")
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find CPPTest (missing: CPPTEST_INCLUDE_DIRS CPPTEST_LIBRARIES
  CPPTEST_LIBRARY_DIRS)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindCPPTest.cmake:24 (find_package_handle_standard_args)
  external/CMakeLists.txt:6 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!
See also "/applications/Geom/OpenVSP/OpenVSP-3.0.4/build/CMakeFiles/CMakeOutput.log".

I have attached the aforementioned log file. Please direct me how to proceed. Thanks.
CMakeOutput.log

Rob McDonald

unread,
Mar 9, 2015, 4:02:43 PM3/9/15
to ope...@googlegroups.com
All of my recent Linux building experience is on Debian, so I don't
have an exact step-by-step for Red Hat. If it comes to it, I can set
up a virtual machine and go through the process for you.

The v3 build system lets you build with a combination of system
installed and VSP-built libraries.

There is a separate library build that will attempt to build all the
libraries you don't want to use from the system. On Mac and Windows,
the expectation is that you will use VSP packaged libraries almost
exclusively.

On Linux, the expectation is that you will use system installed
libraries almost exclusively. That doesn't have to be the case, but
keep in mind that things like our VSP bundled FLTK don't get much
build testing on Linux.

When you run

cmake ../src

You're skipping the libraries build entirely. This is sorta OK, but
it means that CMake will search the system for everything. If you
have all the system libraries installed, this will largely work.
However, there are some libraries that there no packages exist for --
so there is zero chance they will be installed (Code-Eli, possibly
others).

So, if you run

cmake ../SuperProject

The build system will automatically build all the VSP packaged
libraries and then launch the ../src build of VSP itself. If we're
lucky and everything builds on Linux, it should automagically do
everything. I don't expect to be that lucky.

Instead, you can also build the projects separately:

mkdir buildlibs
cd buildlibs
cmake ../Libraries
cd ..
mkdir build
cd build
cmake ../src -DVSP_LIBRARY_PATH=/full/path/to/buildlibs

This process is equivalent to building the SuperProject, but if you're
doing actual VSP development (not just building for a certain
platform), the separate approach may make prettier IDE project files
that are more fun to work with.

In general, I still suggest you install as many system-installed
libraries you can on Linux. The only exception would be if you were
dealing with a sys-admin who absolutely would not install requested
packages. In that case, you quite possibly should be building a
non-graphical version only and the library requirements are
substantially more modest.

Fairly detailed Ubuntu instructions were recently posted to the group.

https://groups.google.com/d/msg/openvsp/YF64iqoFDFs/lxhNwqeP1AsJ

Let me know how you progress. If need be, I'll set up a VM and try to
go through the process myself.

Rob
> --
> You received this message because you are subscribed to the Google Groups
> "OpenVSP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openvsp+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

clyde

unread,
Mar 10, 2015, 8:42:49 AM3/10/15
to ope...@googlegroups.com
Thanks for the suggestion. When I looked closer at the Readme, I saw that cpptest is actually one of the libraries it was presuming is on my system. I had thought the error was just some arcane cmake error. So apparently that is the way cmake reports that a required library is missing. I followed your suggestion to start the VSP-packaged libraries. It built CMINPACK, CODEELI, CPPTEST, EIGEN, and FLTK, but died building GLEW.


CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find OpenGL (missing: OPENGL_gl_LIBRARY OPENGL_INCLUDE_DIR)

Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindOpenGL.cmake:161 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:20 (find_package)

It appears I need to learn about cmake so I can determine where it wants to look for things.

I went into Libraries-build and made GLM and LIBXML2 without issues. It gives me hope that if I figure out GLEW, I might have a shot.

clyde

unread,
Mar 10, 2015, 12:29:16 PM3/10/15
to ope...@googlegroups.com
I also need to determine what in particular it thinks it cannot find. The message says it caonnot find OpenGL  I can find libGL.so, libGLU.so in /usr/lib64. I can find several include files in /usr/include/GL. What more might it want? Or how is it not looking in the right spots?

Rob McDonald

unread,
Mar 10, 2015, 7:49:15 PM3/10/15
to ope...@googlegroups.com
I'm not sure on that one.

FLTK also has to find OpenGL -- if it builds, it would seem that it was able to find it.

GLEW may well be already installed on your system.  You might try -DUSE_SYSTEM_GLEW=true to just skip it...

Rob

D Baier

unread,
Dec 9, 2016, 8:50:05 AM12/9/16
to OpenVSP
Hello, I am trying to get OpenVSP running/built on my Linux workstation in the hopes to include it within a MDAO framework, however I am having problems getting it to build on my system.

I am having very similar problems trying to build OpenVSP on RHEL 6.8. I am not too familiar with cmake, however I have tried following two sets of directions: the ones above suggested by Rob, as well as the ones listed on the wiki (http://www.openvsp.org/wiki/doku.php?id=ubuntu_instructions), however both fail during the build. I'm not sure why, but it does seem that CPPTEST isn't being built correctly (or at all?). I receive the following as command line output -- when doing the above mentioned method to build.

>> cmake ../src -DSVP_LIBRARY_PATH=/home/baierdm/AnalysisTools/OpenVSP/repo/buildlibs/

-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- 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/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done

-- Found Doxygen: /usr/bin/doxygen (found version "1.6.1")
CMake Error at /home/baierdm/Enthought/Canopy_64bit/User/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:148 (message):

  Could NOT find CPPTest (missing: CPPTEST_INCLUDE_DIRS CPPTEST_LIBRARIES
  CPPTEST_LIBRARY_DIRS)
Call Stack (most recent call first):
  /home/baierdm/Enthought/Canopy_64bit/User/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)

  cmake/FindCPPTest.cmake:24 (find_package_handle_standard_args)
  external/CMakeLists.txt:6 (FIND_PACKAGE)

I have also included the CMakeOutput.log for the Library build, as well as the src build.. Any help would be greatly appreciated. I will note that this is a machine where I do not have sudo access.

I have double checked to see what was required (not included with OpenVSP), and I have:
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
SWIG Version 3.0.8
cmake version 3.4.3
Python 2.7
.11 --  64-bit
Doxygen version 1.6.1



-- Configuring incomplete, errors occurred!

CMakeOutput_Libraries.log
CMakeOutput.log

Rob McDonald

unread,
Dec 9, 2016, 10:57:31 AM12/9/16
to ope...@googlegroups.com
CPPTest is the first library that the CMake scripts search for. This
is most likely a discovery problem rather than a build problem.

Are you building the SuperProject, or separate Libraries and VSP?

Rob

D Baier

unread,
Dec 9, 2016, 11:01:38 AM12/9/16
to OpenVSP
Rob, thanks for the reply.

I have tried building both ways (tried SuperProject first), however after building SuperProject failed, I tried the separate Libraries method that you described above. --> the errors I had posted that I am receiving are from the second method (separate libraries and VSP).

Thanks.
-Dalton

Rob McDonald

unread,
Dec 9, 2016, 11:20:59 AM12/9/16
to ope...@googlegroups.com
Ok, the most likely thing is that VSP can't find the libraries you built.

Are you passing -DVSP_LIBRARY_PATH=/path/to/Libraries/subproject to
cmake for VSP?

Rob

D Baier

unread,
Dec 9, 2016, 11:38:18 AM12/9/16
to OpenVSP
Rob, I believe I am passing it the correct directory:

mkdir buildlibs
cd buildlibs
cmake ../Libraries
cd ..
mkdir build
cd build
cmake ../src -DSVP_LIBRARY_PATH=/home/baierdm/AnalysisTools/OpenVSP/repo/buildlibs/


-Dalton

Rob McDonald

unread,
Dec 9, 2016, 11:50:58 AM12/9/16
to ope...@googlegroups.com
After you cmake ../Libraries, you must then make that project.

CMake is a program that builds the build files -- it creates
Makefiles, Visual Studio projects, XCode projects, etc. It doesn't
compile your program.

So, do something like

make -j4

After you run cmake (-j4 tells it to use 4 threads).

Rob

D Baier

unread,
Dec 12, 2016, 9:41:49 AM12/12/16
to OpenVSP
Rob, thanks for all of your help with this.

I haven't had prior experience using CMake, so I appreciate the explanation of what CMake actually does -- it was helpful.

With that, I was able to build/make the Libraries without any errors. However, when I go to  cmake ../src -DVSP_LIBRARY_PATH=/path/to/buildlibs, I get an error stating that some of the variables used in the project are set to NOTFOUND. The terminal output I receive is in cmake_TerminalOutput.log

I ended up starting from a fresh download of the OpenVSP source (I must have messed something up with my prior version because it would only even attempt to build two of the libraries).
cmake_TerminalOutput.log
CMakeOutput.log
CMakeError.log

Rob McDonald

unread,
Dec 12, 2016, 9:49:17 PM12/12/16
to ope...@googlegroups.com
Can you go back and run make again in your Libraries build directory?

The error indicates that the VSP CMake can't find GLEW. That is a
library that should be built in the Libraries subproject. My
expectation is that there was some problem building GLEW that you
didn't see because there are a lot of messages going by when you build
Libraries.

Rob

D Baier

unread,
Dec 13, 2016, 8:17:01 AM12/13/16
to OpenVSP
Rob,

I went ahead and ran make again on the Libraries build directory. I have attached the output here (as well as the output when I make clean & make)... I don't notice anything blatantly wrong with the GLEW build. It does warn that it didn't verify a few files, but the build appears to complete. Looking in ~/buildlibs/GLEW-prefix/bin/, both glewinfo and visualinfo executables exist and give usage information when called from the terminal.

I appreciate all of your help.
make.out
makeOutput.out
terminalWarnings.out
Reply all
Reply to author
Forward
0 new messages