Compiling on Centos 7

[DR Millman]

Rob,

I decided to compile on Centos 7 where I have better luck with graphics. Plus, I have cbaero working there. After yum installing the needed packages, the compile seemed to be going well. Then make threw this error:

Linking CXX executable vspaero

/usr/bin/ld: cannot find -lstdc++

collect2: error: ld returned 1 exit status

make[5]: *** [src/vsp_aero/solver/vspaero] Error 1

make[4]: *** [src/vsp_aero/solver/CMakeFiles/vspaero.dir/all] Error 2

make[3]: *** [all] Error 2

make[2]: *** [OpenVSP-prefix/src/OpenVSP-stamp/OpenVSP-build] Error 2

make[1]: *** [CMakeFiles/OpenVSP.dir/all] Error 2

make: *** [all] Error 2

I do have the libstdc++ library. Any idea on what I need to do to fix this?

Thanks,

Danny

[Rob McDonald]

Since you're to the linking stage, you've at least made it all the way
through the compile.

There are two commonly used standard C++ libraries on Linux. One of
them has historically more up-to-date support for C++ 11, so we
generally favor it in OpenVSP itself. I'm not sure if Dave uses the
same in VSPAERO.

libc++ is the LLVM one libstdc++ is the GCC one.

I'd bet that your Centos machine only installed the dynamic libraries
for the system libraries -- since vspaero is trying to link it in, it
must be looking for the static library. There is probably an
additional yum library that will include the static library. It may
have a -dev suffix, or something similar...

When you run make, you can instead run 'make VERBOSE=1'. This will
cause make to print out the complete command for everything it does.

In this case, the library paths that it is searching for libstd++ will
be identified with a -L.

Though, since these are generally packaged with the compiler, they may
not need to be separately listed.

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.

[DR Millman]

sudo yum install libstdc++-static.x86_64 did the trick. OpenVSP is up and running, and wireframes are displaying correctly. Thanks!

[Rob McDonald]

Awesome!

Would you mind documenting the steps you took on Centos?

I can create a Wiki account for you -- or if you document it in a post
here, I can transfer it to the Wiki.

Rob

[DR Millman]

Wilco. I'll document here.

[DR Millman]

Here is the documentation a colleague of mine compiled for building on Centos7.

[Garrett Gleason]

Rob,

I am trying to build on CentOS 6.8, but there is no static c++ library.  There is a glibc bundled.  How would I go about directing the build to glibc instead of libstdc++?

Thanks,

Garrett

[Rob McDonald]

This isn't about static or dynamic.

We always use dynamic linking to the system libraries -- but we try to
link dynamically to the things we bundle. On Linux, if you use system
installed libraries, we may use dynamic linking to those.

There are two C++ libraries that are commonly used/available on Linux machines:

libc++ -- A c++ standard library developed by the llvm project.
libstdc++ -- A c++ standard library developed by the gcc project

One of these will be installed with your C++ compiler.

There used to be some differences in what level of advanced C++
support these had, but these days, they're both great. You should
just use the one matched to your compiler.

A CentOS machine will default to a gcc compiler, os it should use libstdc++

Why do you think this is a problem?

Rob

[Garrett Gleason]

I built OpenVSP on CentOS 7 similarly to how DR Millman did.  When I tried these same steps in CentOS 6.8 The only two libraries that I could not find to install were libstdc++-static and glm-devel.  I believe I resolved not having the glm library by changing true to false in the cmake command.  My build error was also similar to DR Millman's from the original post in this thread, which he resolved with the libstdc++-static library.

Perhaps I am wrong about the source of the error.  Below is the error from the make command:

make[5]: *** [src/util/CMakeFiles/util.dir/STEPutil.cpp.o] Error 1

make[4]: *** [src/util/CMakeFiles/util.dir/all] Error 2

make[3]: *** [all] Error 2

make[2]: *** [OpenVSP-prefix/src/OpenVSP-stamp/OpenVSP-build] Error 2

make[1]: *** [CMakeFiles/OpenVSP.dir/all] Error 2

make: *** [all] Error 2

I also found this note in the series of error messages.  I don't know if it is relevant or not.

note: #pragma message: Parts of Code-Eli will not work with this version of GCC

Thanks,

Garrett

[Rob McDonald]

It looks like you're trying to compile with an old version of GCC --
it likely doesn't have a good / current C++ library too.

The yellow error message from the 'make' command doesn't tell us
anything, perhaps there is more information somewhere else in the
output.

The Code-Eli message could be more informative, but it requires GCC
4.5 or newer.

If you can install a modern GCC on the machine, it may make the c++
library you need available.

Rob

[Tim Jim]

Hi, not sure if I should open a new topic or use this one. I'm also having trouble compiling on CentOS 7.

I've tried many variations of the cmake commands (including the one in the install notes above) but I think I must be missing something. I searched the forum for different keywords but I'm out of ideas for the minute. Do you happen to know what is causing the build to drop out? I have attached a log of the outputs, and the preceding commands are summarised below.

Any ideas would be greatly appreciated!

Kind regards,

Tim

The furthest I seem to get is when I use the following steps:

1. sudo yum install glibc glibc-static glibc-devel cmake git git-gui libxml2 libxml2-devel fltk fltk-devel fltk-static fltk-fluid cpptest cpptest-devel libjpeg-devel libjpeg-turbo glm-devel glew glew-devel python-devel swig doxygen libstdc++ libstdc++-static eigen3 cminpack cminpack-devel

2. mkdir repo build buildlibs

3. git clone https://github.com/OpenVSP/OpenVSP.git repo

4. cd buildlibs

5. cmake -DCMAKE_BUILD_TYPE=Release -DVSP_USE_SYSTEM_FLTK=false -DVSP_USE_SYSTEM_CPPTEST=false -DVSP_USE_SYSTEM_LIBXML2=true -DVSP_USE_SYSTEM_EIGEN=false -DVSP_USE_SYSTEM_FLTK=false -DVSP_USE_SYSTEM_GLM=true -DVSP_USE_SYSTEM_GLEW=true -DVSP_USE_SYSTEM_CMINPACK=true ../repo/Libraries -DCMAKE_BUILD_TYPE=Release

6. make -j8

7. cd ../build

8. cmake -DVSP_LIBRARY_PATH=../buildlib -DCMAKE_BUILD_TYPE=Release -DVSP_USE_SYSTEM_FLTK=true -DVSP_USE_SYSTEM_CPPTEST=true -DVSP_USE_SYSTEM_LIBXML2=true -DVSP_USE_SYSTEM_EIGEN=false -DVSP_USE_SYSTEM_FLTK=true -DVSP_USE_SYSTEM_GLM=true -DVSP_USE_SYSTEM_GLEW=true -DVSP_USE_SYSTEM_CMINPACK=false ../repo/SuperProject

[Rob McDonald]

First suggestion -- if you build the libraries as a separate step (4,5,6) then you don't have to build the SuperProject.  On step 8, you can replace ../repo/SuperProject with simply ../repo or ../repo/vsp

Second suggestion -- since make spews out a mess of stuff (but is smart enough to not repeat things that work the first time) it is sometimes helpful to repeat the make command after a really long make command.  So, after step 6, I would type in 'make' again.

Finally, after step 8, you need another 'make' command -- to build VSP itself.  You can do make -j8 there if you want, but I know there are some race conditions that cause problems for parallel make of VSP, so you can either repeat the make -j8 a couple of times (after two or three, it will complete if there are no errors), or you can do a non-parallel 'make' and it will take longer, but will eventually finish.

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+unsubscribe@googlegroups.com.

[Tim Jim]

Hi Rob,

Thanks for the message. On trying to cmake using ../repo only, I get an error stating that CodeEli can't be found, giving the following:

/opt/openvsp/build$ cmake -DVSP_LIBRARY_PATH=../buildlibs -DCMAKE_BUILD_TYPE=Release -DVSP_USE_SYSTEM_CPPTEST=true -DVSP_USE_SYSTEM_LIBXML2=true -DVSP_USE_SYSTEM_EIGEN=false -DVSP_USE_SYSTEM_FLTK=true -DVSP_USE_SYSTEM_GLM=true -DVSP_USE_SYSTEM_GLEW=true -DVSP_USE_SYSTEM_CMINPACK=false ../repo

CMake Error at src/CMakeLists.txt:21 (INCLUDE):

  INCLUDE could not find load file:

    ../buildlibs/VSP_Libraries_Config.cmake

-- GLM_INCLUDE_DIR = /usr/include

CMake Warning at src/cmake/FindCodeEli.cmake:97 (message):

  Couldn't find code_eli.hpp

Call Stack (most recent call first):

  src/external/CMakeLists.txt:42 (FIND_PACKAGE)

CMake Error at /opt/cmake/cmake-3.11.0/share/cmake-3.11/Modules/FindPackageHandleStandardArgs.cmake:137 (message):

  Could NOT find CodeEli (missing: CodeEli_INCLUDE_DIRS) (Required is at

  least version "0.3.6")

Call Stack (most recent call first):

  /opt/cmake/cmake-3.11.0/share/cmake-3.11/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)

  src/cmake/FindCodeEli.cmake:145 (find_package_handle_standard_args)

  src/external/CMakeLists.txt:42 (FIND_PACKAGE)

-- Configuring incomplete, errors occurred!

See also "/opt/openvsp/build/CMakeFiles/CMakeOutput.log".

Am I setting my flags incorrectly?

Kind regards,
Tim

[Tim Jim]

I also tried with ../repo/src and with the bare minimal but I get the same error (i.e. running cmake ../repo/src -DVSP_LIBRARY_PATH=../buildlibs -DCMAKE_BUILD_TYPE=Release)

[Tim Jim]

Apologies for posting again, the above issue with CodeEli was solved - it turns out you have to specify the absolute path to cmake:

cmake ../repo/src -DVSP_LIBRARY_PATH=/opt/openvsp/buildlibs -DCMAKE_BUILD_TYPE=Release

However, it is now getting stuck on many undefined references during the cxx build...Is there a way I can troubleshoot what's going on here? (Please seeattached for the outputs).

Many thanks and kind regards,

Tim 

[Tim Jim]

As an update to the latest troubleshooting, after getting desperate, I tried the (slightly hacky-like) solutions posted here and here.

I trialled an errored a few different paths to get it working but now I'm getting some different 'undefined reference to symbol' error. If anyone could give an insight into what I could try next, that would be great. I've pasted my process below and have attached the outputs so far.

########################################

Current attempt:

1. cd buildlibs

2. cmake -DCMAKE_BUILD_TYPE=Release \

-DVSP_USE_SYSTEM_CPPTEST=false \

-DVSP_USE_SYSTEM_LIBXML2=false \

-DVSP_USE_SYSTEM_EIGEN=false \

-DVSP_USE_SYSTEM_FLTK=false \

-DVSP_USE_SYSTEM_GLM=false \

-DVSP_USE_SYSTEM_GLEW=true \

-DVSP_USE_SYSTEM_CMINPACK=true \

-DVSP_USE_SYSTEM_CODEELI=false \

-DVSP_USE_SYSTEM_LIBIGES=false \

../repo/Libraries

3. cd ../build

4. make -j8

# quick fix for FLTK issues

5. cp ../buildlibs/FLTK-prefix/bin/fluid ../repo/src/vsp_aero/viewer/

6. cp ../buildlibs/FLTK-prefix/bin/fluid ../repo/src/fltk_screens/

7. cmake ../repo/src/ -DVSP_LIBRARY_PATH=/opt/openvsp/buildlibs -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/home/tjim/anaconda3/bin/python -DPYTHON_LIBRARY=/home/tjim/anaconda3/lib/libpython3.6m.so -DPYTHON_INCLUDE_DIR=/home/tjim/anaconda3/include/python3.6m -DPYTHON_INCLUDE_PATH=/home/tjim/anaconda3/include

8. Add these lines to CMakeCache.txt replace LIBXML2_INCLUDE_DIR, do NOT replace the LIBRARY path add LIBRARIES:

//Path to a file.

LIBXML2_INCLUDE_DIR:PATH=/usr/include/libxml2

LIBXML2_LIBRARIES:FILEPATH=/usr/lib64/libxml2.so

//Path to a library.

LIBXML2_LIBRARY:FILEPATH=/opt/openvsp/buildlibs/LIBXML2-prefix/lib/libxml2.a

//Path to a library.

PYTHON_LIBRARY_DEBUG:FILEPATH=pdb.py

9. make

I've attached the output of running 'make' a second time so that you can see where I'm getting stuck.

Many thanks and kind regards,

Tim

[Tim Jim]

Hi Rob, any chance you could give a suggestion here? I've been trying but I've still not been able to compile this on my CentOS, apologies to ask again.

[Rob McDonald]

Most likely, CMake is finding parts of the system-installed FLTK and parts of the OpenVSP-hosted one.  It appears that these were compiled with conflicting C libraries.  Try changing to -DVSP_USE_SYSTEM_FLTK=true.

BTW, the VSP_USE_SYSTEM_XXXX all default to False, so you can omit those and shorten the commands considerably.

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+unsubscribe@googlegroups.com.

[Tim Jim]

Dear Rob,

Thank you very much for your hints and help. You were right, it must have been picking up a mix of libraries (probably as a result of me following a mix of walkthroughs)!

For anyone who is trying to compile on a CentOS machine, I've attached the steps that I took to compile OpenVSP 3.16.1 with Python bindings (successfully, I hope).

Thanks again.

Tim

[Rob McDonald]

Problems with the build system almost always boil down to failure of the CMake FindXXX.cmake scripts.  Sometimes they don't find what you want -- other times, they get confused like this.

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+unsubscribe@googlegroups.com.

[Marc Umbricht]

Hi Rob,

I'm trying to install on CentOS and seem to be having different problems than previous posters.

The Terminal Output is :

/opt/OpenVSP/repo/src/geom_core/VSPAEROMgr.cpp: In member function ‘void VSPAEROMgrSingleton::UpdateUnsteadyGroups()’:
/opt/OpenVSP/repo/src/geom_core/VSPAEROMgr.cpp:4318:48: error: no matching function for call to ‘std::vector<UnsteadyGroup*>::erase(std::vector<UnsteadyGroup*>::const_iterator&)’
                 m_UnsteadyGroupVec.erase( iter );
                                                ^
/opt/OpenVSP/repo/src/geom_core/VSPAEROMgr.cpp:4318:48: note: candidates are:
In file included from /usr/include/c++/4.8.2/vector:69:0,
                 from /opt/OpenVSP/repo/src/util/Vec2d.h:19,
                 from /opt/OpenVSP/repo/src/xmlvsp/XmlUtil.h:9,
                 from /opt/OpenVSP/repo/src/geom_core/Parm.h:19,
                 from /opt/OpenVSP/repo/src/geom_core/Link.h:17,
                 from /opt/OpenVSP/repo/src/geom_core/LinkMgr.h:14,
                 from /opt/OpenVSP/repo/src/geom_core/VSPAEROMgr.cpp:12:
/usr/include/c++/4.8.2/bits/vector.tcc:134:5: note: std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::erase(std::vector<_Tp, _Alloc>::iterator) [with _Tp = UnsteadyGroup*; _Alloc = std::allocator<UnsteadyGroup*>; std::vector<_Tp, _Alloc>::iterator = __gnu_cxx::__normal_iterator<UnsteadyGroup**, std::vector<UnsteadyGroup*> >; typename std::_Vector_base<_Tp, _Alloc>::pointer = UnsteadyGroup**]
     vector<_Tp, _Alloc>::
     ^
/usr/include/c++/4.8.2/bits/vector.tcc:134:5: note:   no known conversion for argument 1 from ‘std::vector<UnsteadyGroup*>::const_iterator {aka __gnu_cxx::__normal_iterator<UnsteadyGroup* const*, std::vector<UnsteadyGroup*> >}’ to ‘std::vector<UnsteadyGroup*>::iterator {aka __gnu_cxx::__normal_iterator<UnsteadyGroup**, std::vector<UnsteadyGroup*> >}’
/usr/include/c++/4.8.2/bits/vector.tcc:146:5: note: std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::erase(std::vector<_Tp, _Alloc>::iterator, std::vector<_Tp, _Alloc>::iterator) [with _Tp = UnsteadyGroup*; _Alloc = std::allocator<UnsteadyGroup*>; std::vector<_Tp, _Alloc>::iterator = __gnu_cxx::__normal_iterator<UnsteadyGroup**, std::vector<UnsteadyGroup*> >; typename std::_Vector_base<_Tp, _Alloc>::pointer = UnsteadyGroup**]
     vector<_Tp, _Alloc>::
     ^
/usr/include/c++/4.8.2/bits/vector.tcc:146:5: note:   candidate expects 2 arguments, 1 provided
make[2]: *** [geom_core/CMakeFiles/geom_core.dir/VSPAEROMgr.cpp.o] Error 1
make[1]: *** [geom_core/CMakeFiles/geom_core.dir/all] Error 2

make: *** [all] Error 2

The CMakeError.log is attached.

I am using system files for everything but CodeEli, Stepcode, and LibIGES.  I have tried pointing to the system python files, and it does not seem to make a difference.  Any Suggestions?

On Wednesday, August 15, 2018 at 7:00:08 AM UTC+2, Rob McDonald wrote:

Problems with the build system almost always boil down to failure of the CMake FindXXX.cmake scripts.  Sometimes they don't find what you want -- other times, they get confused like this.

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Rob McDonald]

Have you compiled on this machine in the past?  If so, which version did you last have success?

My gut says that Centos 7 has a really old version of gcc and that we've introduced a language feature that isn't implemented in that version.  I haven't verified it, but we've hit this sort of thing other places.

We have other users stuck on Centos 7 without the ability to use a newer compiler, so this is something I'll want to root out...

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/f447ef36-2ef4-4b42-b318-46f7646beb80o%40googlegroups.com.

[Marc Umbricht]

Hi Rob,

No this is a new server.  I run Fedora on our workstations and CentOS 7 on our compute node. 

I think you might be right about the old GCC.  CentOS 7 uses gcc 4.8.5 according to pkgs.org.  By comparison, Fedora uses gcc 10.0.1.

The good news is that CentOS 8 uses gcc 8.3.1, and should have package parity soonish.  I think most people will start to switch over in the next year or so.

The alternative in the meantime is to compile on a development machine with a newer version of GCC installed and post the .zip file (along with the list of dependencies).  CentOS is a pretty common system so I figure it would be worthwhile.  I could try it out and report back.

On a related note, I was considering volunteering to package OpenVSP for Fedora, so that users can install it directly from the package manager as opposed to compiling.  Would this be OK for you?  

Sincerely,
Marc Umbricht

On Thursday, August 6, 2020 at 6:00:40 PM UTC+2, Rob McDonald wrote:

Have you compiled on this machine in the past?  If so, which version did you last have success?

My gut says that Centos 7 has a really old version of gcc and that we've introduced a language feature that isn't implemented in that version.  I haven't verified it, but we've hit this sort of thing other places.

We have other users stuck on Centos 7 without the ability to use a newer compiler, so this is something I'll want to root out...

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Rob McDonald]

Marc,

Can you try building 3.19.1?  I think that version should build with Centos 7.  If that works, we can probably isolate the new compiler features we're using and try to find other solutions.

We have other users stuck at RedHat 7.7 that will probably run into the same problem when they go to update.

Building on a newer machine and taking the *.zip back likely won't work.  Often, the limitations aren't the compiler per-say, but the version of the standard library that is normally packaged with a particular compiler.  Consequently, if it is a library feature that is missing, you can build on a newer machine, but unless you're going to back port the system standard libraries too, it won't get you very far.

I'd love to have someone figure out a RPM based package -- likely for Fedora.  Ideally, it would be a setup on some sort of build server or CI service -- and the ultimate build artifacts (the binary RPM files) would be something I could download with each new version and post on our website.

For Mac and Ubuntu, we currently use Travis-CI.  We use their GitHub deployment to transfer the build artifact over to GitHub.  That is a bit of a hassle.

For Windows, we currently use Appveyor.  It makes it very easy to set up for different compilers, 32/64 bit, and different Python accompaniment.  It also makes it very easy to download the build artifact at the end of the process without having to set up some other account for it to push the result to.

Gary Gray is going to take a look at that setup and see if we can consolidate to Appveyor or otherwise make the system work better.

I am not sure what kinds of options there are for Fedora / Centos / rpm land, but going to an automated build system is really key to making it practical for us to support.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/ae78ff3c-f038-43cc-85fc-18b0cb1634eco%40googlegroups.com.

[Marc Umbricht]

Hi Rob,

I'll take a look at this tomorrow, but in the meantime, here's a script I wrote for internal use to automate the build on Fedora.  It's far from a clean or standard install script, but it works for us (usually).  openvsp.desktop goes into /usr/share/applications/ for dashboard launching.

Sincerely,
Marc Umbricht

On Saturday, August 8, 2020 at 12:13:34 AM UTC+2, Rob McDonald wrote:

Marc,

Can you try building 3.19.1?  I think that version should build with Centos 7.  If that works, we can probably isolate the new compiler features we're using and try to find other solutions.

We have other users stuck at RedHat 7.7 that will probably run into the same problem when they go to update.

Building on a newer machine and taking the *.zip back likely won't work.  Often, the limitations aren't the compiler per-say, but the version of the standard library that is normally packaged with a particular compiler.  Consequently, if it is a library feature that is missing, you can build on a newer machine, but unless you're going to back port the system standard libraries too, it won't get you very far.

I'd love to have someone figure out a RPM based package -- likely for Fedora.  Ideally, it would be a setup on some sort of build server or CI service -- and the ultimate build artifacts (the binary RPM files) would be something I could download with each new version and post on our website.

For Mac and Ubuntu, we currently use Travis-CI.  We use their GitHub deployment to transfer the build artifact over to GitHub.  That is a bit of a hassle.

For Windows, we currently use Appveyor.  It makes it very easy to set up for different compilers, 32/64 bit, and different Python accompaniment.  It also makes it very easy to download the build artifact at the end of the process without having to set up some other account for it to push the result to.

Gary Gray is going to take a look at that setup and see if we can consolidate to Appveyor or otherwise make the system work better.

I am not sure what kinds of options there are for Fedora / Centos / rpm land, but going to an automated build system is really key to making it practical for us to support.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/ae78ff3c-f038-43cc-85fc-18b0cb1634eco%40googlegroups.com.

[Marc Umbricht]

With 3.19.1, I'm still getting caught on :

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108 (message):

  Could NOT find CodeEli (missing: CodeEli_INCLUDE_DIRS) (Required is at
  least version "0.3.6")
Call Stack (most recent call first):

  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindCodeEli.cmake:145 (find_package_handle_standard_args)
  external/CMakeLists.txt:49 (FIND_PACKAGE)

[Rob McDonald]

Are you building the libraries separate from the main project, or do you use the SuperProject?

Did you have any errors or problems building the libraries?  That error looks like the main project can't find Code-Eli -- which should have been built along with the Libraries.

You got past this step with your earlier procedure, so I'm not sure why this would catch you up now.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/31012e79-c449-4c69-b736-68d616872d34o%40googlegroups.com.