23

I'am finalising an Open Source C coded CometD library, I thought it would be a good idea to open it to OSX/iOS users, like myself.

In order to ease up the work for OSX/iOS developers I wanted to switch from a static C library to a Xcode iOS Static Libary. So I have followed advices found on the net, and generated a static iOS compatible library.

The problem is that, each time when I am trying to use it, I get an error of type :

Undefined symbols for architecture x86_64: ******, referenced from: -********** in *******.a(*******.o)

This error get repeated for almost every C function that I have in my library.

First I thought maybe the library is not x86_64 compatible, empty, or really doesn't have any x86_64 symbol in it.

So I have checked with a "lipo -info" on the library and here is the answer :

enter image description here

To really be sure i also used "nm -arch x86_64" on the library, and went fetching for several undefined functions reported by Xcode as errors. I thought i will be wrong and find nothing but guess what ?

I found the symbols : enter image description here

enter image description here

So my question is :

If the symbols are present in a x86_64 compatible library, why Xcode prompting this error ? Even if I compiling the library for all arm*/s types I am still getting this x86_64 error.

Am I unaware of something or am I just doing it wrong ?

Your answers are always appreciated.

Update (This is the link to the Xcode Project) : https://github.com/GhostGumm/CometD-x86_64-issue

Update 2 : Mr Trojanfoe attracted my attention on a linking Warning I had when compiling. Indeed the linker seemed to miss load the library looking for a directory that doesn't existed. After moving the library to the right directory, linking it manually, the x86_64 error disappeared.

Sadly the problem is still present. Just after a successful compilation, i tried to use the lib , but, when I "alloc" and "init" my main class like so : 

  ZetaFactory *Client = [[ZetaFactory alloc] init];

The x86_64 error comes back roaring with the genuine fierce of a billion suns. I posted the link to the Xcode project, please feel free to test it as i don't have any more ideas on how to fix it, but more importantly why and where this gets buggy.

None the less I will continue to investigate.

soumya
  • 3,801
  • 9
  • 35
  • 69
Hakeem El Bakka-lee
  • 756
  • 1
  • 7
  • 23
  • 1
    Well asked question, with plenty of effort shown. To clarify, you are building for the iOS Simulator, yes? – trojanfoe Aug 04 '15 at 13:16
  • Simulator yes, but also for Devices in a second time. – Hakeem El Bakka-lee Aug 04 '15 at 13:21
  • OK, so the only possibility is that you aren't actually linking against that static library. Check the linker command line in the build tab and make sure it's using the correct values for `-L` and `-l`. – trojanfoe Aug 04 '15 at 13:25
  • I didn't find any -L for the library linking in the "Build Settings" tab. The library i generated is only included in the "Build Phases" -> "Link Binary With Libraries", basically i drag and dropped it. is it wrong to do so ? – Hakeem El Bakka-lee Aug 04 '15 at 14:12
  • I am talking about the actual invocation of the linker in the build tab, not the build settings. – trojanfoe Aug 04 '15 at 14:17
  • Yes i got a Warning of type : Directory not found for option '-L/...' I will see if i can put the directory in the right place and build again. – Hakeem El Bakka-lee Aug 04 '15 at 14:47
  • That's the issue then; you aren't linking against the library. – trojanfoe Aug 04 '15 at 14:48
  • But why is that possible, isn't Xcode supposed to link the static library binary on its own when drag and dropped into the Project, or for this type of static library there is another protocol to follow ? – Hakeem El Bakka-lee Aug 04 '15 at 14:50
  • Yes; if the project is a sub-project and you have set-up a dependency between the main project and the library project, then Xcode will take care of the rest. – trojanfoe Aug 04 '15 at 14:52
  • I manually linked the library, i reported what happened in a second update of the post, if it doesn't bother you to drop an eye on it please. Thank you. – Hakeem El Bakka-lee Aug 05 '15 at 11:49
  • That doesn't make sense for a static library; that's the behaviour I would expect from a dynamic library that was not available at runtime. Static libraries only display that kind of behaviour during linking. – trojanfoe Aug 05 '15 at 12:15
  • @Maresh yep, unresolved. (I talked to him) – Xcrowzz Aug 17 '15 at 07:39
  • The easiest way I have found to simplify/ease situations like these is to delete any \*.so (not \*.so.[0-9]) libraries in the library path, leaving only the static (\*.a) equivalent (forcing the compiler to use your static ones) Sometimes this is easier than getting the build tools to simply not build the shared libs to begin with. – technosaurus Aug 17 '15 at 15:12
  • When `nm` reports `U` for a symbol in an object file, that means the symbol _is referenced but not defined in that object file_ (undefined), and must be serviced from elsewhere. Are you sure you were scanning the actual library expected to contain those symbols? – Iwillnotexist Idonotexist Aug 17 '15 at 20:33
  • A search through your repository "CometD-x86_64-issue" reveals 1 declaration and 1 use of `cometd_create_long_polling_transport` but no definition thereof. Your repository "CarbonComet" does however have a library PLib that contains an implementation; Are you linking against it? Is the file `CarbonComet/PLib/src/http_transport.c` actually compiled in? – Iwillnotexist Idonotexist Aug 17 '15 at 20:41
  • @IwillnotexistIdonotexist i scanned the library that i found in my Xcode project directory. CarbonComet/PLib/src/http_transport.c is a reference from a directory on my computer, i checked copy if needed when importing, and added the files to compiled sources. The library is the compiled C sources into a static library that i processed in XCode that i compile against, is it wrong to do so ? I will manually copy paste the files and see what happens. – Hakeem El Bakka-lee Aug 18 '15 at 09:49
  • why do you have so many things missing on Compile Source and Link Binaries with Library on Build Phases? This may be the problem. – Duck Aug 24 '15 at 11:22

1 Answers1

4

I downloaded and tried to build your project. Looking at the link errors - init_stack_remove_data not found, for example - they're correct. There is no definition of init_stack_remove_data anywhere in your project source.

In the "nm -arch x86_64" output that you cite above, please note that the "U" before a function definition indicates a use of that function, not a definition of it. The nm output is showing that the linker is correct - those functions are called by your code, but are never defined. When they're defined, you'll see a "T" before the function in the nm output.

You need to update your project with the rest of the necessary source before it'll link without errors.

Jon Gotow
  • 161
  • 3
  • I'am wasn't at home for a couple of weeks now, i will update as soon as i reach a Mac Computer or mine at home. I will update the Question as well with a cleaner repository. – Hakeem El Bakka-lee Aug 27 '15 at 09:08