I've got probably what is a simple problem, but there's no informative errors or warnings during compile to alert me to what is going wrong.
I've got a Objective-C++ app that includes a C++ main and ObjC header files.
It builds fine, but when run, it gives this error message:
Dyld Error Message:
Symbol not found: _OBJC_CLASS_$_AppController
Referenced from: /Users/slate/Documents/osirixplugins/eqOsirix/build/Development/rcOsirix.app/Contents/MacOS/rcOsirix
Expected in: flat namespace
in /Users/slate/Documents/osirixplugins/eqOsirix/build/Development/rcOsirix.app/Contents/MacOS/rcOsirix
No amount of googling has resulted in a solution, and I'm sure I've just missed a compilation or build option somewhere.
"AppController.h" is included in the target (checked), and #import'd in the ObjC Class File.
Any help is greatly appreciated.
ObjC++ constantly gives me a headache.
Thanks,
-S!
Clearly the AppController class is missing. Is the AppController class defined in a framework of dynamic library? If so, when you run the app, does it know where to find the libraries/frameworks?
This is a linker issue, by the way. The header files are irrelevant. It's the .m or .mm files you need to look at.
Not sure if this is your issue, but I was having a similar problem with a C++ dll, which took me all day to debug. I haven't programmed in C++ for around 15 years, and while attempting to write a pure virtual function, I used the familiar syntax "virtual void f();" -- oops. In C++ it should be "virtual void f() == 0;" The latest version of gcc on mac OSX 10.9.2 happily compiles the code.
I think it's a perfectly legal forward declaration... however, not sure if C++ allows classes to span multiple files, so it seems like this should be flagged (as no implementation is ever supplied in the CXX file.) In any event, the symbol makes it into the object code, and the linker never complains, so you end up with the missing reference. Hope this helps someone.
Related
I'm working on a library that links another library to use its static functions.
Everything was working perfectly until I switched from including all my code in the header file to sharing it between the .h and .cpp file.
I tried to use ./configure --prefix="<same path as before>" and then make install but ended up with a "/usr/bin/install: cannot stat .libs/<library name>.so.0.0.0': No such file or directory" error. (also, I did change my makefile to accommodate for the inclusion of the .cpp file)
Then, trying to compile my old library (which should've still worked since the linked library didn't make install correctly and was still technically using the older version) I get a pile of errors that seem to have to do with c++ itself. For example:
.../gcc/4.9.1/linux64/include/c++/4.9.1/bits/stl_bvector.h:354:13: error: expected ';' at end of member declaration
There are an absolute ton of errors similar to the one above, all having to do with issues in the path .../gcc/4.9.1/linux64/include/c++/4.9.1/
Has anyone run into this error before? Let me know if I need to provide any more information, it's just that I've never had this happen so I'm at a loss as to where to proceed. It's likely something simple I'm missing but the longer I stare at it the less it makes sense.
Thanks!
Update: I ended up solving the issue I was having. Basically, the .so file was not being accessed, so I used make clean and then the linked library compiled properly. Next, the issues with the base library was just an extra character within a header file that was causing the compiler to blow up with over 1500 lines of errors. After fixing that, it was able to link up properly and is working fine now.
I'm getting the error
Symbol(s) not found for architecture x86_64
Trying to compile a project on QtCreator. It happens when I try to create an instance of an user defined class, Layer. That class consists of a header, layer.h, and a implementation, layer.cpp. It was tested and works in another programs. On my project, it is included in qtwidget.h and the error happens when I try to use it on qtwidget.cpp. For example:
Layer<double> text("pq.txt",0.5,0.5,0.5);
Having this line on qtwidget.cpp is enough for the error to show up.
This is such a generic error that I'm clueless on how to isolate it any further, but if it helps, I've included the whole project on this git repo.
In my opinion, the error message that Qt Creator displays is quite misleading until you understand it, but does not prevent splitting the template class into a header and implementation file. If you think about the message:
Symbol(s) not found for architecture x86_64
the problem, I originally thought when I saw this, is that it states this error on its own in the Issues output and can lead the user into thinking that the problem is due to the architecture. Actually, all its saying is that there's a defined symbol (often function) whose matching implementation wasn't found.
If you change from Issues to the Compile Output window and scroll up, you'll be able to see exactly what symbols can't be found; mine's displayed in red. It's just annoying that the detail of the missing symbol(s) doesn't show up in the Issues view.
It's easy to replicate this error by just adding a function definition into a header and without implementing the function, call it from the .cpp file. You'll then see something like this in the Issues window
Switching to the Compile Output view and scrolling up displays this: -
So now we see that tthe actual problem is that the function DoSomeStuff in the class called PGGui is being called from the constructor PGGui::PGGui, but the body of DoSomeStuff is missing, as its symbol is not found.
Fortunately I've managed to solve my problem before any answers, so, if anyone is experiencing anything similar, the issue was that it seems you can't split a templated class into a .cpp and a .h file. Putting all declarations of the .cpp file back into the .h solved the issue.
I still had a leftover problem, though: duplicated symbols (which was the reason I split it). This time, declaring a variable as external in the .h, and redeclaring it without the external keyword in one (and only one) .cpp file solved the issue for good.
For me this problem resulted from not rebuilding the make file after adding another source file and header.
Under Build:
Cleanall->run qMake->run
fixed the error for me.
The problem in my case was that i had a project with many subproject and one of the pro files of the subprojects was empty.
For me, I forgot to write the name of the class object when declaring the function in .cpp file.
wrong: int Zero(int &num)
right: int Common2::Zero(int &num)
Where Common2 is the class.
I'm trying to port the speakhere example into another app and I'm having issues. I copied all the files, and all the frameworks, but for some reason I get a bunch of compile errors that I've never seen before and thus don't know what to do. The only difference is that i'm not suing IB and so i had to change it slightly.
What does error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo' mean?... I get this error multiple times for different files
In my situation the first error is pointing at 'MeterTable'.. a class that includes <stdlib.h>,<stdio.h> and <math.h>. But those files seem to be importing fine (if i remove them i get more errors)
Any suggestions on how to debug this?
TIA!
EDIT:
I still can't seem to figure it out. I'm literally just copying files from the example into another project. Can someone check it out please ? SpeakHerePort.zip and the original is here SpeakHere.zip
Your problem is that you are compiling SpeakHerePortAppDelegate.m, which is an Objective C file, but it is indirectly including MeterTable.h which is a C++ header file.
Rename it to SpeakHerePortAppDelegate.mm (double m) so that it is compiled as Objective C++ and your problem is resolved.
Name all your files .mm and then all your code will be compiled as Objective C++
In my case, the .h and .m in question are built fine with regular target, and the App can run as well.
However after the subset of the files are moved under a static library target, it gets this compile error when the static library is built.
Was stuck for a while & tried the above mentioned techniques, unfortunately they didn't help in my case.
Noted that this error happened only for the NSString*, for e.g.,
extern double const kTimeout; // fine
extern NSString* const kImageType; // compile error
After the above analysis & little break, eventually the problem is resolved by adding the the following import to the .h - "Foundation/Foundation.h"
It sounds like an unfinished declaration, probably in a header file. Search for 'foo' (or whatever the symbol actually is) across all project files, using ⇧⌘F (Edit ▸ Find ▸ Find In Project...) in Xcode, and/or examine the headers you're including where MeterTable is declared. Sometimes the compiler gets confused about the actual location of the error, since header files are frequently #imported into other files, so the problem can be manifest in multiple locations.
This might not have applied to this exact situation, but I had this exact error too, which was caused by a bad forward declaration. In Objective-C, make sure your forward-declares begin with the # sign - e.g.
#class MyClass;
Those of us still on autopilot from C++ will forget the #, see that XCode has highlighted class as a reserved keyword, and think all is well with the world. It is not.
It means that you have a syntax error. If you paste the code in question, it's easier to debug.
I had a similar scenario to some of the posts above. I'd written a C++ class based off of the examples in the Audio Queue Services documentation, and had this compilation issue in a test project. This post helped a tremendous amount.
Today, I'm incorporating the C++ class in my project, and got the build error again. In my scenario, I had to also set the type (using the "Get Info" window) to sourcecode.cpp.objcpp for the objective-c class that was calling my C++ class.
I made an Objective-C project for the iPhone. I had only one cpp class, the soundEngine taken from some Apple demo. Now I'm trying to merge OpenFeint which is coded in Objective-C++. I dropped in the code, by simply dragging the files and just tick "Call C++ default ctors/dtors in Objective-C" in Project Settings. I am not even referring to it from my code. When I hit Build, my Objective-C code cannot find the methods of the cpp file.
All the class files compile, including OpenFeint's, but in the linking stage it says several of these errors:
"_SoundEngine_SetDisabled", referenced from: someClass.o
Note that it is adding an underscore in front of the methods when it's reporting these linking errors.
P.S. I know that for OpenFeint first thing one should do is convert the files to .mm but if possible I don't want to go down that road at this stage of development. I was going to try create a wrapper Objective-C++ class for it. I read someone managed to do that.
If you're saying you have Objective-C++ files that are not .mm files, then they're not being read as Objective-C++ unless you've done something special to make it so. .mm is the extension for Objective-C++ files. That's why you've been advised to use it.
but in the linking stage it says several of these errors: "_SoundEngine_SetDisabled", referenced from: someClass.o
There's no name mangling on that method. Is it declared as extern "C" in a header somewhere but defined as a C++ method/function.
I am working on a C++ project that uses Qt (gui lib), VTK (graphics lib) and another library which is so obscure I won't mention its name and will instead call it LIB_X. The project uses Qt for the gui components and VTK (more precisely the QVTKWidget extension provided by VTK that supports Qt) for rendering geometry.. and it uses LIB_X to gather and manipulate geometry.
The problem is that it turns out that LIB_X actually uses VTK (where and how, I don't know, it's closed source). At first there was no problem, compiling with both libs linked was going fine, but at some point I called a certain (and highly needed) LIB_X function and compiling led to a bunch of 'blah blah something about a VTK lib/obj already defined in LIB_X dll' errors.
e.g. (and note this is with /FORCE:MULTIPLE so it's a warning here, let me know if you want the error without /FORCE:MULTIPLE and I'll post it):
1>LIB_X.lib(LIB_X.dll) : warning LNK4006: "public: __thiscall std::vector<double,class std::allocator<double> >::~vector<double,class std::allocator<double> >(void)" (??1?$vector#NV?$allocator#N#std###std##QAE#XZ) already defined in vtkCommon.lib(vtkInformationDoubleVectorKey.obj);
I tried using /FORCE:MULTIPLE and it seemed to be a miracle at first, but I am getting random errors in code that would mostly give heap errors. I decided to remove all references to LIB_X from the main project and created a static lib that would handle all LIB_X stuff. I'm not a C++ expert, so I'm not certain how it handles lib clashing when you're using a pre-compiled lib, but I still received lib clashing errors when linking my static lib into my main project, so I still have to use /FORCE:MULTIPLE.
Once I had the static lib it seemed like the random errors had gone away, I was able to do a lot with LIB_X methods in the main project via the static lib, BUT out of nowhere, I added a new data member to my main project's class (a std::vector of doubles) and suddenly I was getting a heap error in one of my static library's methods. If I commented out the new data member, the static library's method would run fine. I hate to give the current error, because honestly I'm not sure if examining it will be worthwhile, but here it is anyway in case it can help:
note: it crashes to xutility on about line 151, pops up assertion:
"file: dbgheap.c line: 1279 expression: _CrtIsValidHeapPointer(pUserData)"
The error comes after adding a vector vector double to a vector vector vector double, crashing on the push_back line:
std::vector<std::vector<double>> tmpVec;
for(srvl_iter = srvl.begin(); srvl_iter != srvl.end(); ++srvl_iter)
{
tmpVec.push_back((*srvl_iter).getControlPoints());
}
this->_splines.push_back(tmpVec); //CRASH
It only started crashing here when I added a new data member to my main project (separate from the static lib!) Commenting out the new data member takes the error away.
std::vector<std::vector<std::vector<double>>> _geometry;
So, /FORCE:MULTIPLE seems bad, I get random errors that just don't make sense to me. Are there other solutions? Am I screwed? Is there something I can do with LIB_X's linking of VTK?
I encountered a bunch of LNK4006 errors when linking my app to a library (call it library LIB_Y) that made heavy use of std::vector<std::string>, which I also did in my app. After a bit of experimenting I found one solution that worked -- wrap LIB_Y in a separate DLL that calls LIB_Y (LIB_Y_WRAPPER, say), and then link the main app against LIB_Y_WRAPPER.
To try out my suggestion you will need to:
Change your "static lib that handles all LIB_X stuff" from a static LIB project into a DLL project (which I will call LIB_X_WRAPPER).
Make sure the header files of LIB_X_WRAPPER don't include any of the LIB_X header files. This is really important because the wrapper needs to completely isolate your app from the data types declared in the LIB_X header files (such as std::vector<double>). Only refer to LIB_X's header files from within the source files of LIB_X_WRAPPER.
Change the declaration of all classes and functions in your static lib to ensure they are exported from the DLL (see this answer if you need details about exporting from a DLL).
This solution worked for me because it kept the instantiation (compiler generated functions) of the std::vector<std::string> class used by LIBY completely separate from the instantiation of std::vector<std::string> in my app.
As an aside, I suspect the cause of the crash you are seeing (you comment it is in the destructor of std::vector<double>) is because the instantiation of std::vector<double> in your app is different to that in LIB_X.
The commenting out is probably just random luck - if you are corrupting the heap you don't always see it right away but an stl vector will allocate and deallocate things left and right so it's no wonder it's finding the error.
Some libs require you include things in a certain order. I am not sure why exactly because to me it seems like giving up and saying you can't design a library properly, but it's the sad fact. So long as you don't include this lib_x anywhere that you include vtk it should be fine, though.
However, they might be fighting over some resource or using something improperly that makes it impossible for them to work together. If you are able to get the compile to work ok by segregating them and it still fails then yes you are just out of luck because it's just a failing in the way that this lib_x was designed and since it's so obscure it's not likely to have been thoroughly debugged against all uses. When something's not widely used it usually ends up being something that works on the developer's machine and project but not necessarily anyone else's.