Unable to load shared object with inherited class in a R package - rcpp

I am creating a R package using Rcpp. In this package, I want to create classes that will not be exported to R, with a class inheriting from another.
I created a package with Rcpp.package.skeleton(), to which I added two files in the src directory.
I have a file A.h:
class A {
public:
virtual ~A();
};
class B : public A {
public:
B();
};
And a file A.cpp:
#include "A.h"
B::B() { }
When compiling the package, I get the following error:
Error in dyn.load(dllfile) :
unable to load shared object '.../test/src/test.so':
.../test/src/test.so: undefined symbol: _ZTI1A
I only find resources about exposing such classes to R, but I am wondering whether it would be possible to use such a class internally, without exposing it to R?
Edit: If I understand correctly, the files necessary for building the package are:
NAMESPACE:
useDynLib(test, .registration=TRUE)
exportPattern("^[[:alpha:]]+")
importFrom(Rcpp, evalCpp)
DESCRIPTION:
Package: test
Type: Package
Title: What the Package Does in One 'Title Case' Line
Version: 1.0
Date: 2020-06-23
Author: Your Name
Maintainer: Your Name <your#email.com>
Description: One paragraph description of what the package does as one
or more full sentences.
License: GPL (>= 2)
Imports: Rcpp (>= 1.0.4)
LinkingTo: Rcpp
RoxygenNote: 7.1.0

This has nothing to do with Rcpp. Your class A is simply "too virtual". If I combine your files A.h and A.cpp with a simple main.cpp of this form
#include <cstdio>
int main(int argc, char *argv[]) {
std::printf("Hello, world.");
}
and try to compile it I also get an error:
edd#rob:/tmp$ g++ -o A A.cpp main.cpp
/usr/bin/ld: /tmp/ccbuZv0r.o: in function `A::A()':
A.cpp:(.text._ZN1AC2Ev[_ZN1AC5Ev]+0xf): undefined reference to `vtable for A'
/usr/bin/ld: /tmp/ccbuZv0r.o: in function `B::~B()':
A.cpp:(.text._ZN1BD2Ev[_ZN1BD5Ev]+0x26): undefined reference to `A::~A()'
/usr/bin/ld: /tmp/ccbuZv0r.o:(.data.rel.ro._ZTI1B[_ZTI1B]+0x10): undefined reference to `typeinfo for A'
collect2: error: ld returned 1 exit status
edd#rob:/tmp$
Which is pretty much what you got from R as well
edd#rob:/tmp$ c++filt _ZTI1A
typeinfo for A
edd#rob:/tmp$
So your package was simply insufficient -- nothing to do with Rcpp.

Related

Dynamic Linker does not resolve symbol although the library is already loaded

I stumbled over the following problem in my large-grown project: I have a set of libraries which depend on each other and on external libraries. Of one dependency ("libvtkCommonCore-*.so"), there are different variants, which need to be used interchangeably. The variants have different suffixes ("libvtkCommonCore-custom1.so", "libvtkCommonCore-custom2.so" and so on). Thus I cannot link the library, which needs symbols from it, directly to the providing library. Rather I link the application of the library which uses it to the appropriate variant and then load my own library.
This approach generally works but fails under some circumstances and I'm a bit lost while finding out what goes wrong.
This situation is working:
Sketch of situation 1
("libA" needs symbols from "libvtkCommonCore". It is loaded at run time by the constructor of some static object in "libB" using a "dlopen" call with flags RTLD_LAZY|RTLD_GLOBAL. libvtkCommonCore* and libB were linked at build time to an executable)
This situation now ceases to work:
Sketch of situation 2
(actually the same as before but complicated by the fact that libvtkCommonCore* and libB are linked to another library libC at build time. This library is loaded from an executable at run time using "dlopen")
I investigated the case by setting LD_DEBUG to "files", "symbols" and/or "binding" and study the output. It reveals that libvtkCommonCore* is loaded, initialized and kept in memory all the time and before libA is loaded. When the linked tries to resolve "SymbolX" in libA, it does not search libvtkCommonCore, although it did for other libraries which needed the same symbol.
Note: I use Linux (Ubuntu 20) with the recent Gcc and CMake. Both the executable in situation 1 and "libC" in situation 2 were built with the flags "-Wl,--add-needed -Wl,--no-as-needed".
Note 2: if I launch the executable in situation 2 with LD_PRELOAD=libvtkCommonCore-custom1.so set, no errors appear.
I would be grateful for any hint how to continue debugging this issue.
A minimum example of the problem is comprised by these files:
libvtkCommonCore-custom1.cpp:
#include <iostream>
void SymbolX()
{
std::cout<<"This just does nothing useful."<<std::endl;
}
libA.cpp:
void SymbolX(); // in libvtkCommonCore-custom1.so
struct LibAStaticObject
{
LibAStaticObject()
{
SymbolX();
}
} libAStaticObject;
libB.cpp:
#include <dlfcn.h>
#include <iostream>
class LibALoader
{
public:
LibALoader()
{
void *handle = dlopen ( "libA.so", RTLD_LAZY|RTLD_GLOBAL|RTLD_NODELETE );
if ( !handle )
{
std::cerr<<"Could not load module library libA!\nReason: " << dlerror() << std::endl;
}
}
} libAloader;
libC.cpp
/*empty*/
executable_situation1.cpp:
#include <iostream>
int main(int argc, char*argv[])
{
std::cout<<"starting."<<std::endl;
return 0;
}
executable_situation2.cpp
#include <iostream>
#include <dlfcn.h>
class LibCLoader
{
public:
LibCLoader()
{
void *handle = dlopen ( "libC.so", RTLD_LAZY|RTLD_GLOBAL|RTLD_NODELETE );
if ( !handle )
{
std::cerr<<"Could not load module library libC.so!\nReason: " << dlerror() << std::endl;
}
}
} libCloader;
int main(int argc, char*argv[])
{
std::cout<<"starting."<<std::endl;
return 0;
}
CMakeLists.txt:
add_library(vtkCommonCore-custom1 SHARED libvtkCommonCore-custom1.cpp)
add_library(A SHARED libA.cpp)
add_library(B SHARED libB.cpp)
target_link_libraries(B dl)
add_library(C SHARED libC.cpp)
target_link_libraries(C vtkCommonCore-custom1 B)
set_target_properties(C PROPERTIES LINK_FLAGS "-Wl,--add-needed -Wl,--no-as-needed -Wl,--copy-dt-needed-entries")
add_executable(executable_situation1 executable_situation1.cpp)
target_link_libraries(executable_situation1 vtkCommonCore-custom1 B)
set_target_properties(executable_situation1 PROPERTIES LINK_FLAGS "-Wl,--add-needed -Wl,--no-as-needed -Wl,--copy-dt-needed-entries") #"-Wl,--no-as-needed")
add_executable(executable_situation2 executable_situation2.cpp)
target_link_libraries(executable_situation2 dl)
Run it by these commands:
$ mkdir build
$ cd build
$ cmake .. && make
$ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./executable_situation1
This just does nothing useful.
starting.
$ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./executable_situation2
./executable_situation2: symbol lookup error: ./libA.so: undefined symbol: _Z7SymbolXv
Indeed, the problem is that in situation 2 the libvtkCommonCore is not in the lookup scope of libA while in situation 1 it is in the global scope.
The only (probably ugly) solution I found was to put in a kind of a stub library that loads libvtkCommonCore along with libB using "dlopen" with option "RTLD_GLOBAL". This places libvtkCommonCore in the global lookup scope. The new library is then linked to libC instead of its direct dependencies.

Linker Error when attempting to use binary external library

I am new to C++, having recently taken a class to introduce me to the language, so I understand the basics of the syntax, but there was no discussion of how to use external libraries and connect them to our code.
I am trying to use the CLP COIN library for solving linear programs from...
http://www.coin-or.org/Clp/userguide/clpuserguide.html#id4766717
From what I read there, it suggested to use the precompiled binary libraries rather than download the source, since I am on Windows 7 platform, as they suggested recompiling on Windows can sometimes introduce problems.
I am simply trying to get the equivalent of Hello World working. Here is the sample code they provided to test with...
* Copyright (C) 2004, International Business Machines Corporation
and others. All Rights Reserved.
This sample program is designed to illustrate programming
techniques using CoinLP, has not been thoroughly tested
and comes without any warranty whatsoever.
You may copy, modify and distribute this sample program without
any restrictions whatsoever and without any payment to anyone.
*/
/* This shows how to provide a simple picture of a matrix.
The default matrix will print Hello World
*/
#include "ClpSimplex.hpp"
int main (int argc, const char *argv[])
{
ClpSimplex model;
int status;
// Keep names
if (argc<2) {
status=model.readMps("hello.mps",true);
} else {
status=model.readMps(argv[1],true);
}
if (status)
exit(10);
int numberColumns = model.numberColumns();
int numberRows = model.numberRows();
if (numberColumns>80||numberRows>80) {
printf("model too large\n");
exit(11);
}
printf("This prints x wherever a non-zero elemnt exists in matrix\n\n\n");
char x[81];
int iRow;
// get row copy
CoinPackedMatrix rowCopy = *model.matrix();
rowCopy.reverseOrdering();
const int * column = rowCopy.getIndices();
const int * rowLength = rowCopy.getVectorLengths();
const CoinBigIndex * rowStart = rowCopy.getVectorStarts();
x[numberColumns]='\0';
for (iRow=0;iRow<numberRows;iRow++) {
memset(x,' ',numberColumns);
for (int k=rowStart[iRow];k<rowStart[iRow]+rowLength[iRow];k++) {
int iColumn = column[k];
x[iColumn]='x';
}
printf("%s\n",x);
}
printf("\n\n");
return 0;
}
I have associated the Include and Lib directories with my project in Visual Studio, but when I attempt to build, get a number of linker errors such as:
Simplex(void)" (??1ClpSimplex##QAE#XZ) referenced in function _main
1>hello.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall CoinPackedMatrix::~CoinPackedMatrix(void)" (??1CoinPackedMatrix##UAE#XZ) referenced in function _main
1>hello.obj : error LNK2019: unresolved external symbol "public: void __thiscall CoinPackedMatrix::reverseOrdering(void)" (?reverseOrdering#CoinPackedMatrix##QAEXXZ) referenced in function _main
1>hello.obj : error LNK2019: unresolved external symbol "public: __thiscall CoinPackedMatrix::CoinPackedMatrix(class CoinPackedMatrix const &)" (??0CoinPackedMatrix##QAE#ABV0##Z) referenced in function _main
1>hello.obj : error LNK2019: unresolved external symbol "public: int __thiscall ClpSimplex::readMps(char const *,bool,bool)" (?readMps#ClpSimplex##QAEHPBD_N1#Z) referenced in function _main
1>hello.obj : error LNK2019: unresolved external symbol "public: __thiscall ClpSimplex::ClpSimplex(bool)" (??0ClpSimplex##QAE#_N#Z) referenced in function _main
As a newbie, I am clueless as to how to approach resolving this issue, since my course only covered debugging associated with code syntax, not linker issues.
Any tips or links to other threads would be of great help. I have been Googling all day, but am at a loss...
I'm not sure exactly what you did to associate the Lib directories with the project, but you'll need to make sure that these are done (the first is often overlooked):
You need to add the library filename to the Project's "Linker/Input/Additional Dependencies" property.
You might also need to place the location of the library in the Project's "Linker/General/Additional Library Directories" property - depending on if you give the proper path or just the filename ion the above property. This is probably what you already did.
Update:
In the dumpbin output you posted, you'll see the following entry:
4C3 0000AE4A SECT98 notype () External | ?readMps#ClpSimplex##QEAAHPEBD_N 1#Z (public: int __cdecl ClpSimplex::readMps(char const *,bool,bool))
In the error message, you'll see this:
1>hello.obj : error LNK2019: unresolved external symbol "public: int __thiscall ClpSimplex::readMps(char const *,bool,bool)" (?readMps#ClpSimplex##QAEHPBD_N1#Z) referenced in function _main
Compare the de-mangled names from the two messages:
public: int __cdecl ClpSimplex::readMps(char const *,bool,bool) // what's in the .lib
public: int __thiscall ClpSimplex::readMps(char const *,bool,bool) // what hello.obj is asking for
You'll see that the two calling conventions are different. Looking on the coin-or.org website, it looks like the library was built with VC 2005. For Microsoft compilers, the libraries cannot always be used with different compiler versions. I suggest that you use VC 2005 if you want to use this pre-built library (you should still be able to get the free Express version here: http://go.microsoft.com/fwlink/?linkid=57034).
FWIW, I tried compiling the example with several MS compilers and got the following results (build only - the program complains about some file being missing when I try to run it:
worked: VC 2005 and VC 2008
failed: VC 6 and VC2010

extern template DLLs and programs (crypto++)

I've been using Crypto++ with VS2005 and VS2010 for a while now. But recently I needed to use it with and application directly. The same code compiles fine when I'm compiling as a DLL and does not compile when compiling as an application.
This is the smallest sample that reproduces the error is this (based on cryptopp561\algparam.h:301 CryptoPP::AlgorithmParametersTemplate
class Base
{
protected:
virtual void MoveInto(void *p) const = 0;
};
template<class T>
class Test: public Base
{
public:
void MoveInto(void * buffer) const
{
Test<T> *x = new(buffer) Test<T>(*this);
}
};
extern template class Test<bool>;
The compilation parameters are the same, only difference that I saw was the configuration type in the project ("Application (.exe)" generates the error and "Dynamic Library (.dll)" does not).
This is the compiler error:
main.h(15): error C2061: syntax error : identifier 'buffer'
main.h(14) : while compiling class template member function 'void Test<T>::MoveInto(void *) const'
with
[
T=bool
]
main.h(20) : see reference to class template instantiation 'Test<T>' being compiled
with
[
T=bool
]
It seems to occur only when theres inheritance. Ommiting : public Base in the class Test declaration makes the error go away.
EDIT:
The problem was in a header included somewhere that defined a a debug version for operator new but didn't declared the placement new version.
Did you #include <new>, the header file that declares placement-new?
Funnily, extern templates are to tell the compiler to not instantiante at some point, so the second error does not make sense to me. Are you certain your compiler has support for extern templates? What if you do the opposite, explicit instantiation:
template class Test<bool>;

VTable Not Generated

First of all, thank you very much for taking the time to look at my question. Second, I have read this and my class does not have any virtual methods I am forgetting to include. I'll go over additional things I have tried after I describe my problem.
I am getting an undefined reference to `vtable for SubcomponentTypeWidget' error when I build my code using gcc version 3.4.6 20060404. Visual Studio 2005 has no issues. I love Linux, but my current political situation has delegated it to the red headed step child that regularly suffers abuse. Hopefully by our powers combined, I can remedy that.
I am using Qt version 4.6.2. I am using gcc 3.4.6 20060404 on Red Hat 4.
This is my header:
#ifndef SubcomponentTypeWidget_h
#define SubcomponentTypeWidget_h
#include <vector>
#include "ui_SubcomponentTypeWidget.h"
#include "Subcomponent.h"
class SubcomponentTypeWidget : public QWidget, public Ui::SubcomponentTypeWidget
{
Q_OBJECT
Q_PROPERTY(QString title READ title WRITE setTitle)
public:
SubcomponentTypeWidget(QWidget* parent,
Models::Subcomponent::SubcomponentType subcomponentType = Models::Subcomponent::kSolid)
: QWidget(parent),
m_subcomponentType(subcomponentType),
m_subcomponentTypeButtonGroup(new QButtonGroup(this))
{
this->initialize();
}
Models::Subcomponent::SubcomponentType subcomponentType() const { return m_subcomponentType; }
void setSubcomponentType(Models::Subcomponent::SubcomponentType type);
void setNonCompatibleTypes(const std::vector<Models::Subcomponent::SubcomponentType>& types);
QString title() const { return m_subcomponentGroupBox->title(); }
void setTitle(const QString &title) { m_subcomponentGroupBox->setTitle(title); }
signals:
void subcomponentTypeChanged();
protected slots:
void handleSubcomponentTypeChoice(int subcomponentTypeChoiceId);
protected:
void initialize();
Models::Subcomponent::SubcomponentType m_subcomponentType;
QButtonGroup* m_subcomponentTypeButtonGroup;
};
#endif // SubcomponentTypeWidget_h
The implementation is here:
#include "SubcomponentTypeWidget.h"
void SubcomponentTypeWidget::setSubcomponentType(Models::Subcomponent::SubcomponentType type)
{
if (type != m_subcomponentType)
{
m_subcomponentType = type;
emit subcomponentTypeChanged();
}
}
void SubcomponentTypeWidget::setNonCompatibleTypes(const std::vector<Models::Subcomponent::SubcomponentType>& types)
{
m_subcomponentTypeButtonGroup->button(static_cast<int>(Models::Subcomponent::kSolid) + 1)->setEnabled(true);
m_subcomponentTypeButtonGroup->button(static_cast<int>(Models::Subcomponent::kComplement) + 1)->setEnabled(true);
m_subcomponentTypeButtonGroup->button(static_cast<int>(Models::Subcomponent::kHole) + 1)->setEnabled(true);
for (std::vector<Models::Subcomponent::SubcomponentType>::const_iterator it = types.begin(); it != types.end(); ++it)
{
m_subcomponentTypeButtonGroup->button(static_cast<int>(*it) + 1)->setEnabled(false);
if (*it == m_subcomponentType)
m_subcomponentTypeButtonGroup->button(static_cast<int>(Models::Subcomponent::kSolid) + 1)->setChecked(true);
}
}
void SubcomponentTypeWidget::handleSubcomponentTypeChoice(int subcomponentTypeChoiceId)
{
if (static_cast<Models::Subcomponent::SubcomponentType>(subcomponentTypeChoiceId - 1) != m_subcomponentType)
{
m_subcomponentType = static_cast<Models::Subcomponent::SubcomponentType>(subcomponentTypeChoiceId - 1);
emit subcomponentTypeChanged();
}
}
void SubcomponentTypeWidget::initialize()
{
this->setupUi(this);
m_subcomponentTypeButtonGroup->addButton(m_solidRadioButton, static_cast<int>(Models::Subcomponent::kSolid) + 1);
m_subcomponentTypeButtonGroup->addButton(m_complementRadioButton, static_cast<int>(Models::Subcomponent::kComplement) + 1);
m_subcomponentTypeButtonGroup->addButton(m_holeRadioButton, static_cast<int>(Models::Subcomponent::kHole) + 1);
m_subcomponentTypeButtonGroup->button(static_cast<int>(m_subcomponentType) + 1)->setChecked(true);
connect(m_subcomponentTypeButtonGroup, SIGNAL(buttonClicked(int)), this, SLOT(handleSubcomponentTypeChoice(int)));
}
The actual error messages I am receiving are:
../lib/libMeshAndGeometry.a(AddAdvancedDialog.o)(.gnu.linkonce.t._ZN20Ui_AddAdvancedDialog7setupUiEP7QDialog+0x955): In function `Ui_AddAdvancedDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddAdvancedDialog.o)(.gnu.linkonce.t._ZN20Ui_AddAdvancedDialog7setupUiEP7QDialog+0x960): In function `Ui_AddAdvancedDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddAdvancedDialog.o)(.gnu.linkonce.t._ZN20Ui_AddAdvancedDialog7setupUiEP7QDialog+0x99b): In function `Ui_AddAdvancedDialog::setupUi(QDialog*)':
: undefined reference to `SubcomponentTypeWidget::initialize()'
../lib/libMeshAndGeometry.a(AddBoxDialog.o)(.gnu.linkonce.t._ZN15Ui_AddBoxDialog7setupUiEP7QDialog+0xfe8): In function `Ui_AddBoxDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddBoxDialog.o)(.gnu.linkonce.t._ZN15Ui_AddBoxDialog7setupUiEP7QDialog+0xff3): In function `Ui_AddBoxDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddBoxDialog.o)(.gnu.linkonce.t._ZN15Ui_AddBoxDialog7setupUiEP7QDialog+0x102e): In function `Ui_AddBoxDialog::setupUi(QDialog*)':
: undefined reference to `SubcomponentTypeWidget::initialize()'
../lib/libMeshAndGeometry.a(AddConeDialog.o)(.gnu.linkonce.t._ZN16Ui_AddConeDialog7setupUiEP7QDialog+0x7ef): In function `Ui_AddConeDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddConeDialog.o)(.gnu.linkonce.t._ZN16Ui_AddConeDialog7setupUiEP7QDialog+0x7fa): In function `Ui_AddConeDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddConeDialog.o)(.gnu.linkonce.t._ZN16Ui_AddConeDialog7setupUiEP7QDialog+0x835): In function `Ui_AddConeDialog::setupUi(QDialog*)':
: undefined reference to `SubcomponentTypeWidget::initialize()'
../lib/libMeshAndGeometry.a(AddCylinderDialog.o)(.gnu.linkonce.t._ZN20Ui_AddCylinderDialog7setupUiEP7QDialog+0x9c4): In function `Ui_AddCylinderDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddCylinderDialog.o)(.gnu.linkonce.t._ZN20Ui_AddCylinderDialog7setupUiEP7QDialog+0x9cf): In function `Ui_AddCylinderDialog::setupUi(QDialog*)':
: undefined reference to `vtable for SubcomponentTypeWidget'
../lib/libMeshAndGeometry.a(AddCylinderDialog.o)(.gnu.linkonce.t._ZN20Ui_AddCylinderDialog7setupUiEP7QDialog+0xa0a): In function `Ui_AddCylinderDialog::setupUi(QDialog*)':
All of my makefiles have been generated from my .pro file using qmake. The main make files, the main .pro file, and the widgets and MeshAndGeometry make and .pro files are attached here as an archive. One of the .ui files is attached here.
I have tried a number of things.
I am sure this is not a stale object file issue. I have built this from scratch and I still have the the problem.
I checked all of my capitalization issues. One of the problems I have noticed with doing most of this on Windows and then moving it to Linux is that people make mistakes with capitalization, and Windows doesn't care about capitalization.
I ran nm -a -C SubcomponentTypeWidget.o to see if the necessary vtable was there, and it wasn't. However, the 'missing' methods were there.
Creating a virtual destructor does not force vtable generation for SubcomponentTypeWidget.
I have tried removing large chunks of SubcomponentTypeWidget's functionality. This results in removing the specific linker error messages for methods, but it does not remove the undefined reference to vtable message. I have removed everything from SubcomponentTypeWidget other than the constructor, and in this case I still receive the "undefined reference to vtable" message, but without any mention to specific methods we are looking for.
Changing the order of which widgets and MeshingAndGeometry are linked in does not help.
I have tried gcc versions 3.4.6 20060404 and 4.1.2 20080704.
Help me, Obi-Wan Kenobi. You're my only hope.
Thank you all very, very much,
-Brian J. Stinar-
went through your codes the error most likely arises from the following statement:
=======================================================
void SubcomponentTypeWidget::initialize()
{
this->setupUi(this);
//rest of codes
}
=======================================================
you are sort of breaking the structure of Qt by making SubcomponentTypeWidget a subclass of Ui::SubcomponentTypeWidget. You are actually using yourself to setup a UI of yourself in this case. Coupled that with the fact that you are using multiple class inheritance, you are just confusing the compiler on which virtual method to refer to during runtime.
Instead of subclassing Ui::SubcomponentTypeWidget, just make it a private variable in SubcomponentTypeWidget
//SubcomponentTypeWidget.h
private:
Ui::SubcomponentTypeWidge ui;
implement the following in your init function and you should be good to go
void SubcomponentTypeWidget::initialize()
{
ui.setupUi(this);
//rest of codes
}
My problem was with solution point number six. I actually did NOT change this order correctly. I was changing the order in the INCPATH instead of the order in the LIBS.
After adding the line MeshAndGeometry.depends = widgets to my master.pro file, running qmake, and running make, this problem went away.
Thank everyone very much for their comments and help.
-Brian J. Stinar-

Linking a Maya client library to libOpenMayalib.a fails, MLibrary::initialize can't be found (even though nm shows libOpenMayalib.a contains it)

I'm trying to link my app with the Maya C++ API, but i get:
Debug/../src/main.cpp:80: undefined reference to `MLibrary::initialize(bool, char*, bool)'
but, nm shows:
nm libOpenMayalib.a | grep initialize
00000000000004b0 T _ZN8MLibrary10initializeEPcb
0000000000000380 T _ZN8MLibrary10initializeEbPcb
0000000000000000 b _ZZN8MLibrary10initializeEbPcbE13isInitialized
which seems to match MLibrary::initialize, that looks like:
class OPENMAYA_EXPORT MLibrary
{
public:
MLibrary ();
virtual ~MLibrary ();
static MStatus initialize (char* applicationName,
bool viewLicense = false);
static MStatus initialize (bool wantScriptOutput,
char* applicationName,
bool viewLicense = false);
static void cleanup( int exitStatus = 0 );
protected:
// No protected members
private:
// No private members
};
The linking process is run with:
g++ -L/usr/autodesk/maya2009-x64/lib -m64 -pthread -Wl,-rpath,/usr/autodesk/maya2009-x64/lib -lOpenMayalib -l3dGraphics -lAG -lAnimEngine -lAnimSlice -lAnimUISlice -lAppVersion -lAshliFX -lAshli -lAutoCam -lawCacheShared -lawnSolver -lawxml2 -lBase -lCgGL -lCg -lCloth -lCommandEngine -lcxaguard -lDataModel -lDebug -lDeformSlice -lDeformUISlice -lDependCommand -lDependEngine -lDevices -lDynSlice -lDynUISlice -lExplorerSlice -lExtensionLayer -lfbxfilesdk -lFoundation -lgcc_s -lGeometryEngine -lguide -lhairlib -lHalf -lHumanIKShared -lHWFoundation -lHWGL -lHWRenderMaya -lHWRender -lIex -liff -lIlmImf -lImage -lImageUI -lImath -lIMFbase -limf -lirc -lJasperSlice -lKinSlice -lKinUISlice -lManips -lMaya -lmocap -lModelSlice -lModelUISlice -lModifiers -lMotionCapture -lNurbsEngine -lNurbsSlice -lNurbs -lNurbsUISlice -lOpenMayaAnim -lOpenMayaFX -lOpenMayaRender -lOpenMaya -lOpenMayaUI -lPolyEngine -lPolySlice -lPoly -lPolyUISlice -lProjectSlice -lPsdTexture -lpython2.5 -lRenderModel -lRenderSlice -lRenderUISlice -lShared -lSharedUI -lstdc++ -lstdc++ -lSubdivEngine -lSubdivGeom -lSubdiv -lSubdivUI -lsvml -ltbbmalloc -ltbb -lTranslators -lUIComponents -lUrchinSlice -lUrchinUISlice -lXm -lzlib -o"BinaryGL3MdlMayaExporter" ./src/Exporter.o ./src/Format.o ./src/Generic.o ./src/Output.o ./src/main.o -lm -lgtk-x11-2.0 -ldl -lpthread -lgdk-x11-2.0
The system is Ubuntu Maverick 10.10, 64-bit, and Maya is 64-bit as well, and compiling with -m64 gives the same result.
I found a similar post http://area.autodesk.com/forum/autodesk-maya/sdk/link-errors-when-using-the-openmaya-api-on-linux/ i took some ideas from his file, like using the -Wl,-rpath, but, that doesn't change anything..
I also tried installing g++-4.1 as it seems to be the one mentioned in the scripts, but that didn't change anything either (current version is g++-4.4)
Thanks in regards
//Johan
The problem is the way you call MLibrary::initialize.
It expects a non-const char string, which is probably fed with a literal char string that is implicitly constant.
What you call is something like lib.initialize(false, "my app", false) which equals MLibrary::initialize(bool, const char*, bool) - this signature is indeed not exported by MLibrary.
What you have to do to make it work is to use a non-const application name, for example:
// char* appName = "my app"; would be deprecated as string literals are always const
char appName[] = {'m','y',' ','a','p','p'};
lib.initialize(false, appName, false);
Note: This is an interface bug as the application name should indeed be fed as a const char* - this bug is fixed in later maya versions.

Resources