Undefined symbols for architecture x86_64

1,268 views
Skip to first unread message

cyu...@ucdavis.edu

unread,
Feb 16, 2016, 10:38:33 PM2/16/16
to symengine
Hi everybody, I'm getting the following error when compiling a test file outside of symengine:

Undefined symbols for architecture x86_64:

  "operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, __mpq_struct const*)", referenced from:

      SymEngine::StrPrinter::bvisit(SymEngine::Rational const&) in libsymengine.a(printer.cpp.o)

      SymEngine::StrPrinter::bvisit(SymEngine::Complex const&) in libsymengine.a(printer.cpp.o)

  "operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, __mpz_struct const*)", referenced from:

      SymEngine::UnivariateSeries::__str__() const in libsymengine.a(series_generic.cpp.o)

      SymEngine::StrPrinter::bvisit(SymEngine::Integer const&) in libsymengine.a(printer.cpp.o)

      SymEngine::StrPrinter::bvisit(SymEngine::UnivariatePolynomial const&) in libsymengine.a(printer.cpp.o)

      operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::map<std::__1::vector<int, std::__1::allocator<int> >, __gmp_expr<__mpz_struct [1], __mpz_struct [1]>, std::__1::less<std::__1::vector<int, std::__1::allocator<int> > >, std::__1::allocator<std::__1::pair<std::__1::vector<int, std::__1::allocator<int> > const, __gmp_expr<__mpz_struct [1], __mpz_struct [1]> > > > const&) in libsymengine.a(dict.cpp.o)

      operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::unordered_map<std::__1::vector<int, std::__1::allocator<int> >, __gmp_expr<__mpz_struct [1], __mpz_struct [1]>, SymEngine::vec_int_hash, std::__1::equal_to<std::__1::vector<int, std::__1::allocator<int> > >, std::__1::allocator<std::__1::pair<std::__1::vector<int, std::__1::allocator<int> > const, __gmp_expr<__mpz_struct [1], __mpz_struct [1]> > > > const&) in libsymengine.a(dict.cpp.o)

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)


This is how I compile: g++ -std=c++11 -I/usr/local/include test2.cpp ~/symengine/symengine/libsymengine.a ~/symengine/symengine/utilities/teuchos/libteuchos.a /usr/local/Cellar/gmp/6.1.0/lib/libgmp.dylib


Any ideas on how to resolve? I only have the following line along with the necessary include guards:

RCP<Symbol> x(new Symbol("x"));

Isuru Fernando

unread,
Feb 16, 2016, 10:40:33 PM2/16/16
to syme...@googlegroups.com
Hi,

This is due to a mismatch in the standard libraries used in compiling of symengine and the test files.

Did you compile symengine with AppleClang?

Isuru Fernando

--
You received this message because you are subscribed to the Google Groups "symengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to symengine+...@googlegroups.com.
To post to this group, send email to syme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/symengine/f97b68f3-1238-4909-8f65-5d4555277ff9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

cyu...@ucdavis.edu

unread,
Feb 17, 2016, 8:44:25 PM2/17/16
to symengine
I compiled it with g++.

Isuru Fernando

unread,
Feb 17, 2016, 8:45:51 PM2/17/16
to syme...@googlegroups.com
That's strange.

Can you post the output of cmake when you compile symengine and also `g++ --version`?

Isuru Fernando

Charles Chen

unread,
Feb 18, 2016, 11:51:44 AM2/18/16
to symengine
CMake output:

-- The C compiler identification is AppleClang 7.0.2.7000181

-- The CXX compiler identification is AppleClang 7.0.2.7000181

-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc

-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++

-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

CMake Warning (dev) in CMakeLists.txt:

  No cmake_minimum_required command is present.  A line of code such as


    cmake_minimum_required(VERSION 3.4)


  should be added at the top of the file.  The version specified may be lower

  if you wish to support older CMake versions for this project.  For more

  information run "cmake --help-policy CMP0000".

This warning is for project developers.  Use -Wno-dev to suppress it.


-- Configuring done

-- Generating done

-- Build files have been written to: /Users/Charles/symengine/symengine





g++ --version:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1

Apple LLVM version 7.0.2 (clang-700.1.81)

Target: x86_64-apple-darwin15.3.0

Thread model: posix



Yes it's using clang. However that should not be a problem.

Isuru Fernando

unread,
Feb 18, 2016, 1:21:55 PM2/18/16
to syme...@googlegroups.com
Hi,

Thanks for the info.

In OS X 10.10 and afterwards, g++ and clang++ are both the same thing. For some reason, I think g++ is using libstdc++ which shouldn't happen. `std::__1::basic_ostream` is a construct in libc++ and the linker cannot find this symbol probably means that you are using libstdc++.

Do you have an environment variable MAC_OSX_DEPLOYMENT_TARGET set and if so what is its value? 
Can you check whether clang++ works or g++ -stdlib=libc++ works?

libstdc++ and libc++ are ABI incompatible, so you cannot link symengine compiled with libc++ and your test program which is compiled with libstdc++. On OS X, I suggest you use clang++ instead of g++ unless you are using C++ libraries compiled in OS X 10.8 (In OS X 10.8, libstdc++ was the default). libstdc++ that ships with OS X tools is basically useless if you want C++11 features.

Isuru Fernando

Ondřej Čertík

unread,
Feb 18, 2016, 1:40:06 PM2/18/16
to symengine
On Thu, Feb 18, 2016 at 11:21 AM, Isuru Fernando <isu...@gmail.com> wrote:
> Hi,
>
> Thanks for the info.
>
> In OS X 10.10 and afterwards, g++ and clang++ are both the same thing. For
> some reason, I think g++ is using libstdc++ which shouldn't happen.
> `std::__1::basic_ostream` is a construct in libc++ and the linker cannot
> find this symbol probably means that you are using libstdc++.
>
> Do you have an environment variable MAC_OSX_DEPLOYMENT_TARGET set and if so
> what is its value?
> Can you check whether clang++ works or g++ -stdlib=libc++ works?
>
> libstdc++ and libc++ are ABI incompatible, so you cannot link symengine
> compiled with libc++ and your test program which is compiled with libstdc++.
> On OS X, I suggest you use clang++ instead of g++ unless you are using C++
> libraries compiled in OS X 10.8 (In OS X 10.8, libstdc++ was the default).
> libstdc++ that ships with OS X tools is basically useless if you want C++11
> features.

Charles, let us know if you need help with any of this. SymEngine
should work with the default AppleClang on OS X (in fact, we test it
with it on Travis). Once we figure out how to compile on your
computer, we should document it in our README.

Ondrej
> https://groups.google.com/d/msgid/symengine/CA%2B01voN3Z5iA40FBChQNX%3DSfUaRJ1M1WGM464dreDtdDbLO4_A%40mail.gmail.com.

Charles Chen

unread,
Feb 18, 2016, 1:57:33 PM2/18/16
to symengine
Isuru,

MAC_OSX_DEPLOYMENT_TARGET is not set.

clang++ and g++ -stdlib=libc++ both produce the same error message as the original.

Isuru Fernando

unread,
Feb 18, 2016, 2:00:47 PM2/18/16
to syme...@googlegroups.com
For linking can you also try adding libgmpxx.dylib?

Isuru Fernando

Charles Chen

unread,
Feb 18, 2016, 2:15:19 PM2/18/16
to symengine
Isuru,

Thanks! The error message is gone now. 
Reply all
Reply to author
Forward
0 new messages