0

I've got a basic assimp example copied from the assimp site (with some minor modifications to make it work with C). Now the problem is that when it tries to link, assimp complains that it can't find ::operator delete(void*) or std::allocator or a lot of other C++ things. Assimp is supposed to work with a plain C interface, so it shouldn't be having this issue, right?

Another note: this is using statically linked assimp v3.3.1 compiled using the same MinGW-w64 compiler.

Here's my sample code which causes the errors:

#include <assimp/cimport.h>
#include <assimp/scene.h>
#include <assimp/postprocess.h>

int DoImport(const char* pFile){
    const struct aiScene* s = aiImportFile(pFile, 
                                           aiProcess_CalcTangentSpace       | 
                                           aiProcess_Triangulate            |
                                           aiProcess_JoinIdenticalVertices  |
                                           aiProcess_SortByPType);
    if(!s)
        return 0;
    return 1;
}

int main(){}

And here are some examples of the errors:

C:/MinGW/bin/../lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/lib/
../lib/libassimp.a(ImporterRegistry.cpp.obj):ImporterRegistry.cpp:(.text$_ZNSt6v
ectorIPN6Assimp12BaseImporterESaIS2_EE19_M_emplace_back_auxIJS2_EEEvDpOT_[__ZNSt
6vectorIPN6Assimp12BaseImporterESaIS2_EE19_M_emplace_back_auxIJS2_EEEvDpOT_]+0x71):
undefined reference to `operator delete(void*)'

C:/MinGW/bin/../lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/lib/
../lib/libassimp.a(DefaultIOSystem.cpp.obj):DefaultIOSystem.cpp:(.text+0x818):
undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_M_create(unsigned int&, unsigned int)'
  • does it work if you link with `g++`? (I suppose it does) – Jean-François Fabre Sep 20 '16 at 19:18
  • You would normally link C code with the C compiler driver, `gcc`. It sounds like you may be linking with the C++ compiler driver, having compiled with the C compiler, or *vise versa*. Otherwise, one or more of your headers must be C++-specific. – John Bollinger Sep 20 '16 at 19:19
  • seems that the lib is written in C++ and misses some standard library static code in the .a itself. – Jean-François Fabre Sep 20 '16 at 19:26
  • @Jean-FrançoisFabre Yes, the library is written in C++, but the site says they support use with a plain C interface, which is what I'm trying to do. On my linux machine, the linking using `gcc` works fine. It's just on windows where I have the issue. –  Sep 20 '16 at 19:30
  • @JohnBollinger I link and compile with `gcc` –  Sep 20 '16 at 19:32
  • If the same code works with `gcc` on Linux but not with `gcc` on MinGW, then it is probably assuming that anything being built on Windows is being built by a C++ compiler, i.e. MSVC++. – John Bollinger Sep 20 '16 at 19:38
  • Do note, by the way, that supporting use with a plain C interface is not at all the same thing as supporting compiling the library itself with a C compiler. It may assume that you will build the library with a C++ compiler, with the comment simply describing the interfaces it exposes in that case. In that event, you could build modules to link with it with a C compiler, but you might need to use the C++ compiler driver to link. – John Bollinger Sep 20 '16 at 19:42
  • Try adding -lstdc++ to the linking command – Anton Malyshev Sep 20 '16 at 19:42
  • @JohnBollinger @AntonMalyshev Ok I'll link with `g++`. I was hoping to find a way around, but I'll make do with it. There's a new problem though: undefined references to `unz*` functions. Which should be a part of zlib, right? But linking with `-lz` or `-lzlibstatic` don't remedy the issue. Any suggestions? –  Sep 20 '16 at 19:50

0 Answers0