CMake Error CentOS 7 "Do not know how to extract"

Jason Welstead

unread,

Mar 17, 2021, 3:14:39 PM3/17/21

to OpenVSP

I am trying to compile OpenVSP v3.23.0 on CentOS 7 and have come across an error that I have not found described in other posts. I am trying to follow the guidance from https://groups.google.com/g/openvsp/c/KRZE7EpZ8Xk/m/UQ3eub2GDwAJ and tried to build both the Libraries and the SuperProject with the same error.

Specifically, I get:

CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:609 (message):

error: do not know how to extract

'/home0/jwelstea/Documents/openvsp/openvsp_repo/Libraries/Triangle-d3d0ccc94789.zip;SOURCE_SUBDIR;src'

-- known types are .bz2, .tar, .tar.gz, .tgz and .zip

Call Stack (most recent call first):

/usr/share/cmake/Modules/ExternalProject.cmake:1420 (_ep_write_extractfile_script)

/usr/share/cmake/Modules/ExternalProject.cmake:1805 (_ep_add_download_command)

cmake/External_Triangle.cmake:8 (ExternalProject_Add)

CMakeLists.txt:62 (INCLUDE)

For some reason it is saying it cannot extract the Triangle zip file. I have dug into External_Triangle.cmake and was not able to find anything obvious. I cloned the repo this morning and made sure I was using the 3.23.0 tag. Thanks!

The entire output:

$: cmake -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 /home0/jwelstea/Documents/openvsp/openvsp_repo/SuperProject/

-- The C compiler identification is GNU 4.8.5

-- The CXX compiler identification is GNU 4.8.5

-- 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

-- Configuring done

-- Generating done

-- Build files have been written to: ~/Documents/openvsp/build/Libraries

$: $ make

Scanning dependencies of target Libraries

[ 5%] Creating directories for 'Libraries'

[ 10%] No download step for 'Libraries'

[ 15%] No patch step for 'Libraries'

[ 21%] No update step for 'Libraries'

[ 26%] Performing configure step for 'Libraries'

-- The C compiler identification is GNU 4.8.5

-- The CXX compiler identification is GNU 4.8.5

-- 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

CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:609 (message):

error: do not know how to extract

'/home0/jwelstea/Documents/openvsp/openvsp_repo/Libraries/Triangle-d3d0ccc94789.zip;SOURCE_SUBDIR;src'

-- known types are .bz2, .tar, .tar.gz, .tgz and .zip

Call Stack (most recent call first):

/usr/share/cmake/Modules/ExternalProject.cmake:1420 (_ep_write_extractfile_script)

/usr/share/cmake/Modules/ExternalProject.cmake:1805 (_ep_add_download_command)

cmake/External_Triangle.cmake:8 (ExternalProject_Add)

CMakeLists.txt:62 (INCLUDE)

-- Configuring incomplete, errors occurred!

See also "/home0/jwelstea/Documents/openvsp/build/Libraries-prefix/src/Libraries-build/CMakeFiles/CMakeOutput.log".

make[2]: *** [Libraries-prefix/src/Libraries-stamp/Libraries-configure] Error 1

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

make: *** [all] Error 2

Rob McDonald

unread,

Mar 17, 2021, 4:55:50 PM3/17/21

to ope...@googlegroups.com

Justin recently changed the bundled triangle. Before, it was a couple of source files thrown in the distribution. Now it is this Zip file.

The new version has better error handling and is more C++ish for better integration.

I believe the file Justin included was produced by GitHub directly and really shouldn't have any problems. We use the same approach to embed CodeEli and several other libraries.

CMake is trying to use its built-in unzip utility to decompress the file. You can also use the same built-in command from the command line.

cmake -E tar "xvf" "Triangle-d3d0ccc94789.zip" --format=zip

I'm not positive about the required quotes above, I think it needs at least some of them.

The -E allows cmake to run one of its bundled utilities as if it was a stand-alone version of the same. CMake bundles tar and a bunch of other unix command line tools to better enable it to have a common capability across platforms -- it can run its bundled tar, copy, rm rename, ls, pwd, sed, awk, etc on Mac, Windows, Linux, etc. without having to worry if the command exists or is exactly the same. From a historical perspective, most of these tools are derived from BSD Unix variants as their license best enabled CMake to incorporate the tools.

I would try running the cmake -E from the command line to see if it works. If it fails, then we need to either update / improve the *.zip file -- or you need to update your CMake on this computer. Perhaps both.

I think it will work -- which means that your script is failing to make the above call in an appropriate way. Look back at the error message....

CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:609 (message):

error: do not know how to extract

'/home0/jwelstea/Documents/openvsp/openvsp_repo/Libraries/Triangle-d3d0ccc94789.zip;SOURCE_SUBDIR;src'

-- known types are .bz2, .tar, .tar.gz, .tgz and .zip

Notice _everything_ between the quotes. The file name includes ;SOURCE_SUBDIR;src appended to the end. That isn't the file name...

Something is happening that appends all that crap to the end of the file name being fed to the CMake -E tar. Since that abomination isn't really a file, it also isn't a zip file, and tar can not decompress it.

So, we have something wrong in the CMake files that specifies that file name or passes it around or something like that.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/ad5595e5-f2ab-4daf-a6b3-f0b17fcea122n%40googlegroups.com.

Rob McDonald

unread,

Mar 18, 2021, 4:45:09 PM3/18/21

to ope...@googlegroups.com

I had a moment to dig a little further.

It looks like the problem is in Libraries/cmake/External_Triangle.cmake.

The formatting of the files is done with spaces rather than tabs. CMake handles these line continuations differently, so it wraps the following line SOURCE_SUBDIR "src" onto the end of the file name which messes everything up.

If you need me to make a patch, I can -- it should be just as easy for you to make the change on your end and then push a change back towards Justin to keep track of.

Rob

jrwel...@gmail.com

unread,

Mar 18, 2021, 5:10:03 PM3/18/21

to ope...@googlegroups.com

Real quick response (kid duty).

I noticed the spaces as well. Converted spaces to tabs to try and match Code Eli file. Didn’t work, but will double check as I was doing it quickly earlier this afternoon.

Cmake version is 2.8.x.y where I don’t remember x and y. Version is definitely 2.8 as the scripts indicate is required.

I’ll follow up after I double check formatting. Was first suspicious about line endings.

Jason Welstead

Sent From My Phone

On Mar 18, 2021, at 4:45 PM, Rob McDonald <rob.a.m...@gmail.com> wrote:

You received this message because you are subscribed to a topic in the Google Groups "OpenVSP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openvsp/o2afr67DSng/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/CAEppYpEWD047tkjsmp%3D45vVuD302zpWaUX4BVcb8fwtwOxQGRA%40mail.gmail.com.

Rob McDonald

unread,

Mar 18, 2021, 5:30:06 PM3/18/21

to ope...@googlegroups.com

You are correct -- line endings deserve your suspicion.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/717A9CAB-5A70-43CC-BD75-E5EC643D1F85%40gmail.com.

Jason Welstead

unread,

Mar 23, 2021, 9:56:49 AM3/23/21

to OpenVSP

It appears that this is a cmake version issue and not a formatting issue, at least from my testing. With the file pulled directly from the repo, I can get it to run using cmake3 version 3.17.5. After removing extra lines at the top of the file and matching tab formatting to External_CodeEli.cmake, cmake version 2.8.12.2 still does not work. Was the SUBDIR command added after that version?

I have resolved this issue on my system, but cmake requirement of v2.8 may need to be updated?

Jason

jvgr...@gmail.com

unread,

Mar 23, 2021, 6:25:48 PM3/23/21

to OpenVSP

Jason,

Glad you were able to get it working. It does appear that the new Triangle library actually requires CMake 3.5 or higher but OpenVSP only requires CMake 2.8 or higher. Hopefully users will be OK with us increasing the minimum requirement to compile OpenVSP themselves. Rob, do you know if there is anyone that not going to be able to update to CMake 3.5?

Thanks,

Justin

Rob McDonald

unread,

Mar 23, 2021, 7:27:38 PM3/23/21

to ope...@googlegroups.com

3.5 seems very aggressive, but it is hard to tell.

The bad thing about CMake version requirements is that they are complete crap. That is almost by design.

There is no way to test your project's CMakeLists.txt to see what version is really required.

Some projects (like the C++ version of Triangle) most likely just set the minimum required to whatever version the developer had installed on their computer that day. Since developers usually work on pretty new OS's and up-to-date software, that will be an advanced version (like 3.5). The fact is, it could probably work with something else much older, but who knows.

For example, the LibIGES developers blindly set their requirement to 3.0 (because that is what they have run it with) and that breaks some of our systems (I don't remember which). Perhaps that will have changed with all the changes from Travis CI to GitHub Actions, but I don't know.

Here is a guide to the version of CMake included with various Linux distributions. I would generally try to identify which versions have been identified as long-term-service by each distro -- and which have been deprecated. I would recommend we try to support all of the big Linux distributions that are still supported by their upstream project.

CentOS follows Red Hat. So, if important user's Linux machines are on CentOS 7, then I think we still need to support 2.8.12...

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/291b6cbd-74f2-4c26-b3b0-cbf9460ca7a1n%40googlegroups.com.

jvgr...@gmail.com

unread,

Mar 24, 2021, 1:15:58 PM3/24/21

to OpenVSP

Rob,

It seems like 2.8 is still the minimum default version on a handful of old Linux distributions. I can try testing out whether or not Triangle can compile with a CMake version less than 3.5, but am not sure the best way to do this. Do you think a VM would be a good approach for creating the build environment? Would it be possible to test out on the "build" branch with GitHub Actions? Considering that the Triangle CMake minimum version was set to 3.5 when the CMakeList files were first created for the project, my guess is that earlier CMake versions will work if we simply reduce the minimum version number identified in Triangle.

Thanks,

Justin

Rob McDonald

unread,

Mar 24, 2021, 1:37:42 PM3/24/21

to ope...@googlegroups.com

I don't have a comprehensive answer.

Basically, CMake Minimum Required Version flags are pretty worthless and I don't think they are worth expending a lot of effort trying to sort them out.

I would start at the other end.

We have a file that doesn't work because of a CMake version issue -- so we have a known bad version and a known good version. This issue has nothing to do with Triangle (which seems to be working fine with older versions) so let's leave that out of it.

You can look at CMake Changelogs to try to find what changed to make the breaking file work. The easiest fix may be to not use whatever syntax we're using there. Otherwise, if we need to keep that syntax, then identifying the CMake change will also identify a specific version which will start to give us a minimum required target.

Until CMake develops a tool to audit the files and truly identify a minimum required version, this will always be a mess.

Unfortunately, too many libraries use it in a lazy manner.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/2b165cd3-fd36-42ed-ba76-8b63697f36d4n%40googlegroups.com.

jvgr...@gmail.com

unread,

Mar 29, 2021, 6:00:20 PM3/29/21

to OpenVSP

I've been trying to get Triangle to compile with CMake 2.8.12 on Ubuntu 12.04.05 but haven't had any success. I'm getting errors for missing internal CMake variables, such as "CMAKE_VERSION_COMPILER" and "CMAKE_1.7.0_COMPILER_ENV_VAR". It appears that Triangle may actually require 3.5 or higher as specified in it's CMakeLists.txt file. It's possible it will work with CMake 3.0 but I still need to test it out.

-Justin

Rob McDonald

unread,

Mar 29, 2021, 6:26:09 PM3/29/21

to ope...@googlegroups.com

Maybe, but I doubt it.

I looked through the CMakeLists.txt files for Triangle. It doesn't do anything exotic. Unless I'm missing something, it should work with very old and basic CMake.

Did you fully delete the CMakeCache.txt when trying different versions?

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/f391c428-f85f-4a97-b147-1f8802f659f9n%40googlegroups.com.

jvgr...@gmail.com

unread,

Mar 29, 2021, 8:11:08 PM3/29/21

to OpenVSP

Rob,

I was able to get a bit further by removing "VERSION 1.7" from the call to "project" at the beginning of the CMakeLists.txt in the Triangle src directory. Now I'm getting a "export unknown arguments" CMake error further down on the same CMakeLists.txt file. I'm not entirely sure what the "write_basic_package_version_file" and "export" calls are intending to accomplish, so I'll need to spend some time learning about them. So far I haven't found anything about an "EXPORT" input to the "export" function not being available in CMake 2.8.12. Please let me know if you have any suggestions.

Thanks,

Justin

jvgr...@gmail.com

unread,

Apr 6, 2021, 8:00:09 PM4/6/21

to OpenVSP

I believe I figured out the changes needed to support CMake 2.8 and above in Triangle. It's pushed it up to my fork of the library here. We can integrate that version with OpenVSP going forward.

-Justin

Jason Welstead

unread,

Apr 8, 2021, 9:23:38 AM4/8/21

to OpenVSP

Thanks for the note about the changes for CMake compatibility. It has been a while since I have posted as I have been going down various avenues trying to race to the finish line. I'm coming up a bit short. On our directorate Linux system on CentOS 7, I have found several versions of CMake and C and C++ compilers. I can successfully set up all the Libraries and VSP with CMake version 3.17.5. I have multiple versions of GCC (4, 6, 7, 8, and 9) and G++ (4, 7, 8, and 9). I can successfully compile the libraries ONLY with g++ version 4.8.5. All other versions error indicating I am missing packages LEMON, RE2C, and PERPLEX. Our SA found LEMON and RE2C via yum, but not PERPLEX and was going to look into that more. Why is it found/not required for 4.8.5 but all other versions of g++?

Moving forward after successfully compiling the Libraries with gcc (any version) and g++=4.8.5...

I am using the no graphics options, so that simplifies the required libraries. If I compile using g++ 4.8.5 I get the following error, which is different than if I use any newer version of g++.

Error compiling VSP using GCC and G++ 4.8.5:

...in file MeshGeom.cpp.o:

/usr/include/c++/4.8.2/bits/stl_algo.h:2263:35: error: invalid initialization of reference of type ‘TEdge&’ from expression of type ‘const TEdge’

while (__comp(*__first, __pivot))

^

/usr/include/c++/4.8.2/bits/stl_algo.h:2266:34: error: invalid initialization of reference of type ‘TEdge&’ from expression of type ‘const TEdge’

while (__comp(__pivot, *__last))

...in file VSPAEROMgr.cpp.o:

/home0/jwelstea/Documents/openvsp/openvsp_repo/src/geom_core/VSPAEROMgr.cpp: In member function ‘void VSPAEROMgrSingleton::UpdateUnsteadyGroups()’:

/home0/jwelstea/Documents/openvsp/openvsp_repo/src/geom_core/VSPAEROMgr.cpp:4321:48: error: no matching function for call to ‘std::vector<UnsteadyGroup*>::erase(std::vector<UnsteadyGroup*>::const_iterator&)’

m_UnsteadyGroupVec.erase( iter );

^

/home0/jwelstea/Documents/openvsp/openvsp_repo/src/geom_core/VSPAEROMgr.cpp:4321:48: note: candidates are:

In file included from /usr/include/c++/4.8.2/vector:69:0,

from /home0/jwelstea/Documents/openvsp/openvsp_repo/src/util/Vec2d.h:19,

from /home0/jwelstea/Documents/openvsp/openvsp_repo/src/xmlvsp/XmlUtil.h:9,

from /home0/jwelstea/Documents/openvsp/openvsp_repo/src/geom_core/Parm.h:19,

from /home0/jwelstea/Documents/openvsp/openvsp_repo/src/geom_core/Link.h:17,

from /home0/jwelstea/Documents/openvsp/openvsp_repo/src/geom_core/LinkMgr.h:14,

from /home0/jwelstea/Documents/openvsp/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>::

^

Error compiling VSP using GCC and G++ 8.2.0:

/home0/jwelstea/Documents/openvsp/openvsp_repo/src/vsp/apitest_main.cpp: In function ‘bool run_tests()’:

/home0/jwelstea/Documents/openvsp/openvsp_repo/src/vsp/apitest_main.cpp:34:58: error: no matching function for call to ‘Test::Suite::add(std::unique_ptr<Test::Suite>)’

ts.add(std::unique_ptr<Test::Suite>(new APITestSuite)); //This line can be copied to add new test suites

^

In file included from /usr/include/cpptest.h:34,

from /home0/jwelstea/Documents/openvsp/openvsp_repo/src/geom_api/APITestSuite.h:15,

from /home0/jwelstea/Documents/openvsp/openvsp_repo/src/vsp/apitest_main.cpp:17:

/usr/include/cpptest-suite.h:58:8: note: candidate: ‘void Test::Suite::add(std::auto_ptr<Test::Suite>)’

void add(std::auto_ptr<Suite> suite);

^~~

/usr/include/cpptest-suite.h:58:8: note: no known conversion for argument 1 from ‘std::unique_ptr<Test::Suite>’ to ‘std::auto_ptr<Test::Suite>’

/home0/jwelstea/Documents/openvsp/openvsp_repo/src/vsp/apitest_main.cpp:35:66: error: no matching function for call to ‘Test::Suite::add(std::unique_ptr<Test::Suite>)’

ts.add(std::unique_ptr<Test::Suite>(new APITestSuiteMassProp));

This repeats about 6 times with the full output included in the attached output.

I feel like I am almost there, just can't limp to the finish line...

Jason

error_w_820.txt

error_w_485.txt

Jason Welstead

unread,

Apr 8, 2021, 9:49:21 AM4/8/21

to OpenVSP

If I try to take a big hammer to it by commenting out all the run_tests() function code in apitest_main.cpp, I get the following out (sorry, it is ugly):

$ make -k

[ 2%] Built target sixseries

[ 4%] Built target tritri

[ 4%] Built target clipper

[ 5%] Built target wavedragEL

[ 11%] Built target pinocchio

[ 27%] Built target Angelscript

[ 38%] Built target util

[ 39%] Built target xmlvsp

[ 67%] Built target geom_core

[ 75%] Built target cfd_mesh

[ 76%] Built target geom_api

Scanning dependencies of target apitest

[ 76%] Building CXX object src/vsp/CMakeFiles/apitest.dir/apitest_main.cpp.o

[ 77%] Linking CXX executable apitest

../cfd_mesh/libcfd_mesh.a(SurfaceIntersectionMgr.cpp.o): In function `SurfaceIntersectionSingleton::WriteSTEPFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, double, bool, bool, bool, bool, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int)':

SurfaceIntersectionMgr.cpp:(.text+0xfd49): undefined reference to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

../cfd_mesh/libcfd_mesh.a(NURBS.cpp.o): In function `NURBS_Curve::WriteSTEPEdge(STEPutil*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)':

NURBS.cpp:(.text+0x955): undefined reference to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

../util/libutil.a(CADutil.cpp.o): In function `STEPutil::MakePlane(vec3d, vec3d, vec3d, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':

CADutil.cpp:(.text+0x3403): undefined reference to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

../util/libutil.a(CADutil.cpp.o): In function `STEPutil::RepresentUntrimmedSurfs(std::vector<SdaiB_spline_surface_with_knots*, std::allocator<SdaiB_spline_surface_with_knots*> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':

CADutil.cpp:(.text+0x35d9): undefined reference to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

../util/libutil.a(CADutil.cpp.o): In function `STEPutil::MakeCurve(std::vector<vec3d, std::allocator<vec3d> >, int const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool, double)':

CADutil.cpp:(.text+0x39bd): undefined reference to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

../util/libutil.a(CADutil.cpp.o):CADutil.cpp:(.text+0x481b): more undefined references to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' follow

../util/libutil.a(CADutil.cpp.o): In function `STEPutil::WriteFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)':

CADutil.cpp:(.text+0x54ba): undefined reference to `STEPfile::WriteExchangeFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, int, int)'

../util/libutil.a(CADutil.cpp.o): In function `STEPutil::STEPutil(int const&, double const&)':

CADutil.cpp:(.text+0x55d5): undefined reference to `STEPfile::STEPfile(Registry&, InstMgr&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool)'

../util/libutil.a(CADutil.cpp.o): In function `STEPutil::MakeSurfaceCurve(std::vector<vec3d, std::allocator<vec3d> >, int const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, double)':

CADutil.cpp:(.text+0x60a8): undefined reference to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

../util/libutil.a(CADutil.cpp.o): In function `STEPutil::MakeSurf(eli::geom::surface::piecewise<eli::geom::surface::bezier, double, (unsigned short)3, eli::util::tolerance<double> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, double)':

CADutil.cpp:(.text+0x7c3a): undefined reference to `SDAI_String::SDAI_String(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

collect2: error: ld returned 1 exit status

make[2]: *** [src/vsp/apitest] Error 1

make[2]: Target `src/vsp/CMakeFiles/apitest.dir/build' not remade because of errors.

make[1]: *** [src/vsp/CMakeFiles/apitest.dir/all] Error 2

[ 77%] Linking CXX executable vspscript