There is a static class Pipe, defined in C++ header that I'm including.
The static method I'm interested in calling (from Objective-c) is here:
static ERC SendUserGet(const UserId &_idUser,const GUID &_idStyle,const ZoneId &_idZone,const char *_pszMsg);
I have access to an objective-c data structure that appears to store a copy of userID, and zoneID -- it looks like:
#interface DataBlock : NSObject
{
GUID userID;
GUID zoneID;
}
Looked up the GUID def, and it's a struct with a bunch of overloaded operators for equality. UserId and ZoneId from the first function signature are #typedef GUID
Now when I try to call the method, no matter how I cast it (const UserId), (UserId), etc, I get the following linker error:
Ld build/Debug/Seeker.app/Contents/MacOS/Seeker normal i386
cd /Users/josh/Development/project/Mac/Seeker
setenv MACOSX_DEPLOYMENT_TARGET 10.5
/Developer/usr/bin/g++-4.2 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -L/Users/josh/Development/TS/Mac/Seeker/build/Debug -L/Users/josh/Development/TS/Mac/Seeker/../../../debug -L/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/i686-apple-darwin10/4.2.1 -F/Users/josh/Development/TS/Mac/Seeker/build/Debug -filelist /Users/josh/Development/TS/Mac/Seeker/build/Seeker.build/Debug/Seeker.build/Objects-normal/i386/Seeker.LinkFileList -mmacosx-version-min=10.5 -framework Cocoa -framework WebKit -lSAPI -lSPL -o /Users/josh/Development/TS/Mac/Seeker/build/Debug/Seeker.app/Contents/MacOS/Seeker
Undefined symbols:
"SocPipe::SendUserGet(_GUID const&, _GUID const&, _GUID const&, char const*)", referenced from:
-[PeoplePaneController clickGet:] in PeoplePaneController.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Is this a type/function signature error, or truly some sort of linker error? I have the headers where all these types and static classes are defined #imported -- I tried #include too, just in case, since I'm already stumbling :P
Forgive me, I come from a web tech background, so this c-style memory management and immutability stuff is super hazy.
Edit: Added full linker error text. Changed "function" to "method". Also I'll note that we're using a custom makefile to compile a few projects external to this one. SocPipe static methods are referenced elsewhere, though, in this xcode project and seems to compile fine.
(Eh, let's turn that comment into an answer.)
The method signature looks fine; that is, what you're calling matches what is declared in the header. If it was not, you would probably be getting a compilation error rather than a linker error.
The linker's problem is that it doesn't have any corresponding object code to connect this call to: the method is declared but never defined.
The latter should occur either in a C++ source file which your project can compile, or else in some precompiled library or framework that you can link to. Either way, that file needs to be included in your project so that it can be made available to the linker.
The object file containing Pipe::SendUserGet is not being built, or it is not being linked into your Xcode target. Whether or not other static methods in Pipe work correctly is not necessarily relevant if those methods are defined in the header file.
You mentioned that you use external makefiles to build parts of your project. In that case, it's not enough to run the makefile at compile time as a dependency — you also have to include the resulting products in your project.
For example, if you have a makefile that builds libLIBRARY.a, then drag libLIBRARY.a into your project and add it to your target.
This only works if the makefile is building a library. It won't work if the makefile builds a program. It also gets more complicated if the library is a dynamic library, as you'll also have to make sure that the dynamic library gets distributed with your application (often by putting it in the app bundle, if you're making an app bundle). It also gets more complicated if you want to build a universal binary. You could theoretically pass the right CFLAGS to make to build a universal library, but it may be easier to run make once for each architecture and combine the results using a script (which is what I do).
Related
There are a lot of questions about this on the web but I couldn't solve my problem. I've been studying this for a few days.
I want run a simple C++ class on Swift project, to this I followed this tutorial: http://www.swiftprogrammer.info/swift_call_cpp.html.
Basically I've followed the steps:
Create junk.cpp and junk.h files
Compile using g++ or/and clang++
Create .a file with: $ ar r libjunkcpp.a junk.o
ranlib libjunkcpp.a
Linked to Xcode in Build Phases -> Link Binary With Libraries -> Add
When I compiles, the follow errors occurs:
Undefined symbols for architecture x86_64:
"A::getInt()", referenced from:
_getIntFromCPP in wrapper.o
"A::A(int)", referenced from:
_getIntFromCPP in wrapper.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
junk.h
class A {
public:
A(int);
int getInt();
private:
int m_Int;
};
junk.cpp
#include "junk.h"
A::A(int _i) : m_Int(_i) {}
int A::getInt() {
return m_Int
}
wrapper.cpp
#include "junk.h"
extern "C" int getIntFromCPP() {
// Create an instance of A, defined in
// the library, and call getInt() on it:
return A(1234).getInt();
}
bridge.h
int getIntFromCPP();
This is an issue that sometimes occurs when using C or C++ libraries that get bridged through Objective-C into Swift. The issue isn't with how the Archive (static library) is built -- rather, it's a problem with an overly-aggressive linker creating the application.
The problem is that the linker sees the binding symbols and the C++ symbols, but never sees it being called from anywhere because it is actually invoked from a different language (Swift). This ultimately results in the linker aggressively stripping all symbols that it doesn't believe are being used in an effort to save space, which effectively removes all of the C++ code.
When this happens, nm will report the correct symbols as existing in the archive, but the actual application will fail to execute due to the symbols not being found.
As for solutions, there are actually several questions/answers already on Stack Overflow that address this issue in varying degrees:
How to disable C++ dead code stripping in xcode, where the solution is to use the linker flag -force_load to force that the static symbols are actually loaded.
Keeping Xcode from stripping out unused symbols from a static library which suggests using __attribute__((constructor)) to trick the linker into thinking the symbols are needed on construction, thus keeping them in.
Xcode Archive debug strip errors, which more broadly suggests toggling some Xcode configurations that may result in the symbols not being stripped. The suggestions in the answers here may conflict with the above two links, however.
It is difficult to provide a definitive and clear answer without more information on the existing setup, such as where wrapper.cpp is built, and how the bindings get used from within the Swift project. Given that this question is from 2018, I don't suspect there will be much more information on what this setup was at the time.
From the described symptoms, this sounds exactly like the issue my colleagues faced when doing C++/Swift bindings -- and the solution was ultimately to use -force_load which ensures that the archive is preserved in totality into the final application.
Recently I found an example of how to use the expect library in C++. I tried to compile it, but the compiler (g++) said, that tcl8.5/expect.h doesn't exists. So I tried to include tcl8.6/expect.h - still the same error. I checked the /usr/include/ directory and I wasn't surprised when I've noticed, that there is no tcl8.x directory.
I've searched for files with "expect" in their name. Here's what I found:
/usr/include/expect_tcl.h
/usr/include/expect_comm.h
/usr/include/expect.h
Unfortunately when I tried to include any of these I got the following list of errors during compilation:
> g++ test.cpp -Wall -std=c++0x -ltcl8.6 -lglog -o test
/tmp/cce8k1BA.o: In function `task(std::string const&, std::string const&, std::string const&)':
test.cpp:(.text+0x16): undefined reference to `exp_is_debugging'
test.cpp:(.text+0x20): undefined reference to `exp_timeout'
test.cpp:(.text+0x38): undefined reference to `exp_popen'
etc...
How can I solve this problem?
[EDIT]
When I tried to link it with the expect lib (-lexpect) I got the following error:
/usr/bin/ld: cannot find -lexpect
collect2: error: ld returned 1 exit status
I'm sure that both - tcl8.6 and expect 5.45-4 are installed.
The usual way of distributing Expect these days puts the shared library in a non-standard location and loads it dynamically by full pathname. This works well and is minimal fuss for most people, but does make it rather hard to use Expect's C interface in your own code.
The easiest way is going to be to build your own copy from source, especially as that will give you control over how exactly it was built. This can particularly include keeping the majority of symbols in the library instead of stripping them on install, which will help a lot with debugging. You probably ought to use the current supported version. (Yes, it's a release from several years ago. It doesn't need a lot of support effort most of the time.)
You haven't linked to the expect library during your build. Add -lexpect to your g++ command.
I'm writing in C++ under XCode 4.6 on Mountain Lion. I'm trying to add and use the Apache log4cxx library. I installed the library this morning via Brew. I'm linking against liblog4cxx.dylib. I'm getting a link error that just one symbol can't be found:
Undefined symbols for architecture x86_64:
"log4cxx::Logger::forcedLog(log4cxx::helpers::ObjectPtrT
const&, std::__1::basic_string,
std::__1::allocator > const&, log4cxx::spi::LocationInfo const&)
const", referenced from:
I know it's finding the library file because if I remove it, I get lots more undefined symbol errors relating to log4cxx.
relevant code is basically:
#include <log4cxx/logger.h>
static LoggerPtr logger(log4cxx::Logger::getLogger("foo.bar.Baz"));
void foo(int p1, int p2)
{
LOG4CXX_WARN(logger, "blah blah blah");
}
Creating the logger object inside the function, either as static or not, doesn't change the behavior. Also, linking with the static library, with or without defining LOG4CXX_STATIC in my project, does not change the behavior.
Looking at the macro I'm calling, I see that this symbol is the actual method that performs the log operation. If take out the logging call but leave in the code that defines the logger object, the code links fine as you might expect.
What do I need to do to have this last symbol resolve?
TIA!
I traced my issue down to compiling the library in a non C++11 compiler, but then my target project was a C++11 compiler.
I was able to compile log4cxx in a C+11 compiler by viewing the changes to log4cxx in the development git repo, which mainly consisted of inserting static_casts, as in this update:
http://apache-logging.6191.n7.nabble.com/C-11-does-not-allow-char-literals-with-highest-bit-set-unless-cast-td34908.html
I suppose the few incompatible routines came up undefined, which is why we were getting confused with only a few seemingly random undefines. (Or I was anyway)
I have Core static library, a few Component static libraries that relays on the Core one, and then there is an App that links against both Core and Component libraries. My App can link both against Core and Component as long as Component don't uses classes from Core (App uses classes from Core).
I got the following error in both armv6 and armv7 versions. So my problem is not the very popular linking issue that everyone has.
ld: symbol(s) not found for architecture armv6
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I added reference to Core in Component and even added it in "Link Binary With Libraries" which shouldn't be necessary for static lib.
Since I start having this issue I start doubting my design... It probably makes more sense in dynamically linking environment but still it should be doable in static one, especially since this already works under Windows with MSVC compilers.
Edit:
I made some progress! Although I still don't know where to go with it.
Here is my setup:
Core has a class cResourceManager that has a templated method GetResource<T>(int id)
Core also has class cResource
Component has class cMesh that inherits cResource
Here are some tests:
If I try from App to call rm->GetResource<cMesh>(...) I get the linking error
If I try from App to construct cMesh I get linking the linking error
If I try from App to call static method that will return new instance of cMesh I get the linking error
If I comment out the construction of cMesh but leave other member cMesh function calls the App links fine. I can even call delete mesh.
I have never seen anything like it!
If you remove the cMesh constructor, then you are then using the default (no argument, no body) cMesh constructor that is given to you. It almost sounds like there's a build error or missing code as a result of some code in your cMesh constructor and so the library isn't actually getting generated, and perhaps Xcode isn't reporting the error. Xcode is no good at reporting linker errors.
I would suggest looking at what symbols the linker says are missing and double-check that they are actually defined in your code. My guess is that you're using one of those symbols in your cMesh constructor. A lot of times with virtual base classes, you may forget to define and implement a method or two in a child class. Could be a result of missing a method based on your template, or your template isn't #included correctly. This could compile fine but result in linker errors like you're seeing.
If Xcode isn't showing you the full linker error, show the Log Navigator (Command ⌘+7), double-click the last "Build " entry, select the error, and then press the button on the far-right of the row that appears when selected. The symbols should be listed there. If not, it's time for xcodebuild in the Terminal.
If it's not that case, I'd be interested in seeing the results of whether or not the library is being built for the appropriate architecture, or maybe this can spur some progress:
In the Xcode Organizer Shift ⇧+Command ⌘+2, click Projects and find the path to the DerivedData for your project.
In the Terminal, navigate to that directory (cd ~/Library/Developer/Xcode/DerivedData/proj-<random value>/)
Remove (or move aside) the Build directory (rm -r Build)
In Xcode, try to build with the cMesh constructor present.
Find the Library product file (cd Build/Products/<scheme>-iphoneos)
Your compiled static libraries (<libname>.a) should be in this directory. If they're not there, they didn't build (unless you put your products elsewhere). If your libraries are there, let's confirm that they actually are getting built for the appropriate architecture. Run otool -vh <library>.a. You should see something like:
$ otool -vh libtesting.a
Archive : libtesting.a
libtesting.a(testing.o):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC ARM V7 0x00 OBJECT 3 1928 SUBSECTIONS_VIA_SYMBOLS
As you can see, my test library was built for ARMv7.
Make sure you are linking them in the correct order.
If Component depends on symbols in Core, then Component needs to be first in the link order, so the linker knows which symbols to look for in Core.
In MSVC the order doesn't matter, but in most other compiler suites it does.
I don't think Clang generates code for armv6, if you're targeting devices that old you still need to use GCC.
I have been trying to build the logstalgia project (http://code.google.com/p/logstalgia/) on my Mac (10.5). Rather than having to link it to the system libraries correctly, I have built and added all of the dependencies to the project. I am new at this, but I do think I have done this correctly, mostly because I have had two of my friends who are much more experienced say so.
Adding the frameworks removed all of the compile errors, but I still get a linker error. It seems to not be able to find the main() function. I have verified I included main.cpp in the sources to be compiled (using XCode) and that there are no accidental double declarations. I have also verified that the main function is correctly declared (no missing brackets, etc).
It is as though XCode does not link in the correct order. Any help would be really appreciated, I am really excited to be down to a single error! (Hope fixing this does not open a floodgate).
Thanks,
Hamilton
PS - I can definitely provide a zip of the Xcode project if anyone is willing to look!
Checking Dependencies
Ld "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug/Untitled" normal i386
cd "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled"
setenv MACOSX_DEPLOYMENT_TARGET 10.5
/developer/usr/bin/g++-4.0 -arch i386 -isysroot /developer/SDKs/MacOSX10.5.sdk "-L/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug" -L/sw/lib "-L/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/../../pcre-7.9/.libs" -L/opt/local/lib -L/sw/lib "-F/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug" -F/Users/hamiltont/Downloads/logstalgia-0.9.2 -F2/src/SDL.framework "-F/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled" -filelist "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Untitled.build/Debug/Untitled.build/Objects-normal/i386/Untitled.LinkFileList" -mmacosx-version-min=10.5 -framework OpenGL -lpcre -lSDL -lSDL_image-1.2.0 -prebind -o "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug/Untitled"
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I got this error to go away. If I understand, essentially SDL re-names the main function, so that it can do some stuff, then run your application, then clean up. Turns out that if you are building in Xcode, you must use ObjectiveC to compile your application.
In Xcode, telling the linker to try and use SDL_main(), rather than just main() does not work (for some technical reasons that are a bit beyond me). So, you include a few Objective C files. In Oc, you get the benefit of being able to say explicitely what the name of your main class is. Hence, the Objective C files you include seem to do nothing more than let Xcode know to look for SDL_main().
In summary, this really had nothing to do with Logstalgia, but was entirely a problem with getting SDL to link correctly in Xcode. This link is talking about this problem exactly. The SDLMain.h and SDLMain.m are Objective C files. If you can't find them, try googleing "Setting up SDL templates in Xcode." I installed the templates in Xcode, used one of them to create an empty project that would compile, link, and run (and promptly do nothing!) and then I added the project files I wanted to the pre-configured project.
Thanks!
Double-check the link file list to make sure main.cpp's object file is present there:
/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Untitled.build/Debug/Untitled.build/Objects-normal/i386/Untitled.LinkFileList
You might also want to preprocess the main.cpp to make sure main isn't getting inadvertently renamed (via a rogue macro) or omitted (via a rogue #if).