3

I'm having trouble with swig and to me it looks like it is saying that one of the data members of my code is an undefined symbol. I have found answers online on how to fix functions but this is puzzling me.

My error is:

Traceback (most recent call last):
  File "./test1.py", line 5, in <module>
    from volumes import *
  File "/scratch/rjkern/projects/RJKERN_volrend/scripts/volumes.py", line 26, in <module>
    _volumes = swig_import_helper()
  File "/scratch/rjkern/projects/RJKERN_volrend/scripts/volumes.py", line 22, in swig_import_helper
    _mod = imp.load_module('_volumes', fp, pathname, description)
ImportError: /scratch/rjkern/projects/RJKERN_volrend/scripts/_volumes.so: undefined symbol: _ZN13ConstantColorC1ESt10shared_ptrI5ColorE

And this is my code:

/*
 *  ColorOperations.h
 */

#ifndef ___COLOROPS___
#define ___COLOROPS___

#include "Color.h"
#include "ProgressMeter.h"
#include "Vector.h"
#include "Volume.h"
#include "VolumeOperations.h"

#include <memory>

using namespace std;

class ConstantColor : public Volume<Color>{
    shared_ptr <Color> color;

public:
    ConstantColor(const shared_ptr<Color>& _color);

    const Color eval(const Vector& P) const;
    Color grad(const Vector& P);
};
#endif

And:

/*
 *  ColorOperations.cpp
 */

#include "ColorOperations.h"

ConstantColor::ConstantColor(const shared_ptr<Color>& _color){
    color = _color;
}

const Color ConstantColor::eval(const Vector& P)const{
    return *color;
}
Flexo
  • 87,323
  • 22
  • 191
  • 272
Justin Kern
  • 31
  • 1
  • 2

1 Answers1

17

We can de-mangle the symbol name with c++filt:

c++filt _ZN13ConstantColorC1ESt10shared_ptrI5ColorE

Which gave:

ConstantColor::ConstantColor(std::shared_ptr<Color>)

i.e. your constructor which takes a shared_ptr. Only the first unresolved symbol will be reported though.

Notice that here it's not a reference, but your constructor looks like it takes a reference. Possible typo somewhere in your .i or other files might explain why something thinks there's a non-reference version.

The other likely explanation for that would be that you've built your wrapper, (i.e. compiled volumes_wrap.cxx) to a shared object, but not linked your compiled ColourOperations.cpp to that object.

Alternatively it's possible that if you have linked it you linked it in the wrong order and thus it was judged as not needed by the linker. If that's the case make sure you have the -lcolour_library/colour_library.a/ColorOperatios.o last on the linker command line. (The name there was speculation).

Community
  • 1
  • 1
Flexo
  • 87,323
  • 22
  • 191
  • 272
  • 2
    Thanks for the `c++filt` tip. It's awesome! – jorgeca Dec 17 '12 at 21:52
  • I'm really late to the party here, but I'm having the same issue. My CPP code runs fine when I'm not using SWIG, but when I use SWIG and try to run my Python script, I get an "Undefined symbol" error. Can you expand on "you've built your wrapper... to a shared object, but not linked your compiled ColourOperations.cpp to that object" ? Also, in the post you linked, I don't understand what they're doing in the third `gcc` line. I've only been executing similar to the first two for my situation. – Alex Eastman Jul 22 '20 at 13:50
  • Often you're going to end up with two shared libraries out of this. There's the library you actually want to wrap firstly. Secondly there's the library that is the shared object your target language needs to load as a language extension, the swig bit. Something needs to make sure that loading the language extension loads the real library it's wrapping otherwise you'll get errors like this. That can be done in a few ways, if the library you're wrapping is static then linking it (correctly) is sufficient. If it's a shared library also you can link it again. Or you can manually use dlopen. – Flexo Jul 23 '20 at 07:39