Build appleseed on Mac


#1

Hi, everybody,

I’m trying to compile appleseed on my mac(osx 10.13.6), have followed the instructions on the wiki.
The problem is it failed linking the denoiser, complaining undefined symbol error, it cannot find some of the bcd library function.
Never encounter this kind problem on my linux machine, not sure why.

Any advice would be appreciated.


#2

Hi,

Can you paste the exact error message(s) please?


#3
Undefined symbols for architecture x86_64:

"bcd::ICallbacks::ICallbacks()", referenced from:

__GLOBAL__sub_I_main.cpp in main.cpp.o

"bcd::ICallbacks::~ICallbacks()", referenced from:

Callbacks::~Callbacks() in main.cpp.o

Callbacks::~Callbacks() in main.cpp.o

"bcd::MultiscaleDenoiser::MultiscaleDenoiser(int)", referenced from:

launchBayesianCollaborativeDenoising(int, char const**) in main.cpp.o

"bcd::SpikeRemovalFilter::filter(bcd::DeepImage<float>&, bcd::DeepImage<float>&, bcd::DeepImage<float>&, bcd::DeepImage<float>&, float)", referenced from:

launchBayesianCollaborativeDenoising(int, char const**) in main.cpp.o

"bcd::Utils::separateNbOfSamplesFromHistogram(bcd::DeepImage<float>&, bcd::DeepImage<float>&, bcd::DeepImage<float> const&)", referenced from:

parseProgramArguments(int, char const**, ProgramArguments&) in main.cpp.o

"bcd::ImageIO::loadMultiChannelsEXR(bcd::DeepImage<float>&, char const*)", referenced from:

parseProgramArguments(int, char const**, ProgramArguments&) in main.cpp.o

"bcd::ImageIO::loadEXR(bcd::DeepImage<float>&, char const*)", referenced from:

parseProgramArguments(int, char const**, ProgramArguments&) in main.cpp.o

"bcd::ImageIO::writeEXR(bcd::DeepImage<float> const&, char const*)", referenced from:

launchBayesianCollaborativeDenoising(int, char const**) in main.cpp.o

"bcd::IDenoiser::IDenoiser()", referenced from:

launchBayesianCollaborativeDenoising(int, char const**) in main.cpp.o

"bcd::IDenoiser::inputsOutputsAreOk() const", referenced from:

launchBayesianCollaborativeDenoising(int, char const**) in main.cpp.o

"typeinfo for bcd::ICallbacks", referenced from:

typeinfo for Callbacks in main.cpp.o

"vtable for bcd::Denoiser", referenced from:

launchBayesianCollaborativeDenoising(int, char const**) in main.cpp.o

NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.

ld: symbol(s) not found for architecture x86_64

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

#4

Thanks, this is helpful.

We don’t build appleseed for macOS regularly, only when we’re preparing releases, so from time to time appleseed doesn’t build on macOS out of the box.

I’ll look into it.


#5

Hi @joey,

I cannot reproduce your problem. I just built appleseed from scratch on a fresh macOS 10.14 VM. I just followed the build instructions from our wiki and everything built flawlessly.

Just to confirm:

  • Are you building the master branch?
  • Is your master branch up-to-date?
  • Do you have any local changes?

One thing to try is to wipe out your build/ directory inside appleseed/ and build appleseed from scratch.


#6

Thank you @franz
I do have some local modifications, for the cmake part, but I think it shouldn’t be the problem. I’ll try to follow your advice and built it from scracch and will post the result here.


#7

Still got no luck.
But I’ve try to modify the source like this:

class ICallbacks
{
public:

  • ICallbacks();
  • ICallbacks() {};
  • virtual ~ICallbacks();
  • virtual ~ICallbacks() {};

    virtual void progress(const float i_progress) const = 0;

@@ -137,9 +137,9 @@ struct DenoiserOutputs
class IDenoiser
{
public:

  • IDenoiser();
  • IDenoiser(): m_callbacks(nullptr) {};
  • virtual ~IDenoiser();
  • virtual ~IDenoiser() {};

    bool inputsOutputsAreOk() const;

basically move the definition of the functions which the linker complains can’t find into the header, it do solves the problem.
I didn’t do all the replacement. But I noticed that all these functions caused problem use classes from IDenoiser.h, but the IDenoiser.cpp doesn’t include IDenoiser.h directly. I don’t know why code is structured like this.
And one more thing, it uses clang to compile code even when you type gcc on OSX by default. I’m not sure if you are using the real gcc. if so, then there must be some implications for clang to handle the code structure. Not sure about it.


#8

Thanks for the details, we’ll look it (we didn’t write the denoiser).

I’m using the default compiler on macOS, that’s clang 10:

Franzs-Mac:Ship franz$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin`

#9

Don’t bother with this, it turns out to be my fault, my modification to cmake files caused this problem. Built successfully now.
The true problem was actually caused by the find_package(PythonLibs), it sets the wrong python include path and library path, on my machine the python was installed into:
“/usr/local/Cellar/[email protected]/2.7.15_1/…”
but the FindPythonLibs set the path to:
“/usr/local/Cellar/[email protected]/2.7.15/…”
make the compiler complaining cannot find pyconfig.h. I hard code the paths for now, better way should be providing our FindPythonXXX.cmake module to find the right paths.

And another thing is, it’s common a mac have both qt5 and qt4 installed (through brew install), the link set in /usr/local/bin/qmake depends on the order you install the packages. Need to link it to the qt4’s qmake.
And in the FindQt4.cmake it uses “qmake -query” to find the paths, the default result is wrong. I write a qt.conf file into /usr/local/bin to fix this.
Not sure if you guys have encountered these issues on your mac, hope this information will be helpful.


#10

Thanks for the update @joey!

I haven’t encountered the Qt 4 vs Qt 5 problem. If you end up finding a clean solution to it, we would certainly appreciate a patch.

Note that we will soon switch from Qt 4 to Qt 5, I don’t know if the problem will still be relevant after the switch.