How to Ice Bilder on XCode 8 without plugins.

Hi again,

Thanks a lot for your advices. We can now compile our slices into Objective-C files manually, (and even automatically too, using the script you provide in your link: https://github.com/zeroc-ice/ice-builder-xcode )

The app seems to see the slices now in the build process, but we think that it must be some kind of problem at link process. A set of symbols appear undefined (all of them are Ice related symbols), and build stops with 42 errors like:

Undefined symbols for architecture x86_64:

  "_ICEInternalCheckModeAndSelector", referenced from:
      +[Z41Z41LANConnect getChallenge___:current:is:os:] in Z41_LAN.o
      +[Z41Z41LANConnect connect___:current:is:os:] in Z41_LAN.o
      +[Z41Z41DiscoverReply reply___:current:is:os:] in Z41_LAN.o
      +[Z41Z41Discover lookup___:current:is:os:] in Z41_LAN.o
      +[AnnouncementZ41Announce announce___:current:is:os:] in Announcement.o
      +[AnnouncementZ41Announce sendAlarm___:current:is:os:] in Announcement.o
      +[AnnouncementZ41Announce request___:current:is:os:] in Announcement.o
      ...
  "_ICEInternalLookupString", referenced from:
      -[Z41Z41LANConnect dispatch__:is:os:] in Z41_LAN.o
      -[Z41Z41DiscoverReply dispatch__:is:os:] in Z41_LAN.o
      -[Z41Z41Discover dispatch__:is:os:] in Z41_LAN.o
      -[AnnouncementZ41Announce dispatch__:is:os:] in Announcement.o
      -[AnnouncementMobileAnnounce dispatch__:is:os:] in Announcement.o
      -[PairingZ41PairingResult dispatch__:is:os:] in Pairing.o
      -[PairingZ41Pairing dispatch__:is:os:] in Pairing.o
      ...
  "_OBJC_CLASS_$_GLACIER2RouterPrx", referenced from:
      objc-class-ref in Z41IceCommWAN.o
    (…)

It seems like the app can’t find the references to the IceTouch iphoneos.SDK symbols. We have revised our XCode 7 config (Additional SDK, User Header Search Paths, Other linker flags) and it’s the same which worked with the previous plug-in. We haven’t changed any configuration or path to our IceTouch installation, but it doesn’t work. This is our XCode concrete configuration. (Remember, we only can use Ice 3.5.1 version)

- Additional SDK:       /Library/Developer/IceTouch-1.3/SDKs/ObjC/$(PLATFORM_NAME).sdk
- Header Search Paths:  /Library/Developer/IceTouch-1.3/SDKs/ObjC/$(PLATFORM_NAME).sdk/usr/local/include
- Other linker flags:          We always have had this field empty in XCode 7 and it worked. 

If we try to set it to the flags you include in your link for Objective-C, the build process show 150 errors like:


    Undefined symbols for architecture x86_64:
  "std::string::find_last_of(char const*, unsigned long) const", referenced from:
      (anonymous namespace)::getStackTrace() in libIceObjC.a(IceUtilCpp_Exception.o)
  "std::string::find_first_of(char const*, unsigned long) const", referenced from:
      IceInternal::stringToMajorMinor(std::string const&, unsigned char&, unsigned char&) in libIceObjC.a(IceCpp_Protocol.o)
      IceInternal::Reference::toString() const in libIceObjC.a(IceCpp_Reference.o)
      IceInternal::RoutableReference::toString() const in libIceObjC.a(IceCpp_Reference.o)
      (anonymous namespace)::getStackTrace() in libIceObjC.a(IceUtilCpp_Exception.o)
      IceUtilInternal::Options::checkArgs(std::string const&, std::string const&, bool, std::string const&) in libIceObjC.a(IceUtilCpp_Options.o)
  "std::string::find_first_of(std::string const&, unsigned long) const", referenced from:
      IceInternal::ReferenceFactory::create(std::string const&, std::string const&) in libIceObjC.a(IceCpp_ReferenceFactory.o)
      IceInternal::UdpEndpointI::UdpEndpointI(IceInternal::Handle<IceInternal::Instance> const&, std::string const&, bool) in libIceObjC.a(IceCpp_UdpEndpointI.o)
      IceInternal::UdpEndpointI::UdpEndpointI(IceInternal::Handle<IceInternal::Instance> const&, std::string const&, bool) in libIceObjC.a(IceCpp_UdpEndpointI.o)
      IceInternal::EndpointFactoryManager::create(std::string const&, bool) const in libIceObjC.a(IceCpp_EndpointFactoryManager.o)
      IceInternal::OpaqueEndpointI::OpaqueEndpointI(std::string const&) in libIceObjC.a(IceCpp_OpaqueEndpointI.o)
      IceInternal::OpaqueEndpointI::OpaqueEndpointI(std::string const&) in libIceObjC.a(IceCpp_OpaqueEndpointI.o)
      IceObjC::EndpointI::EndpointI(IceUtil::Handle<IceObjC::Instance> const&, std::string const&, bool) in libIceObjC.a(EndpointI.o)
  ...

Note 1: Our IceTouch location is (and always was): /Library/Developer/IceTouch-1.3.3
Note 2: We have an alias (“IceTouch-1.3”) that points to IceTouch-1.3.3 folder. That mustn’t be the problem, cause we have test the path with the real folder directly too. It also worked with XCode 7.
Note 3: $(PLATFORM_NAME) appears like “iphoneos”. That constant mustn’t be the problem cause we have replaced by real string and it doesn’t work.

* Any ideas of what’s going wrong?
* Is it possible that your previous plug-in linked IceTouch library in some way that we must config now? How could we do it?
* Is there any other way to link your IceTouch library in XCode that could work?

We’ve spent a lot of hours searching a solution without success, and we can’t support our customers if we can’t build the app. Thanks a lot again in advance.

UPDATE: We have noticed that we have used slice2obj (or Icebuilder script) without options. There are info about 2 params in that link: https://doc.zeroc.com/display/Ice36/slice2objc+Command-Line+Options but we don’t know if the plugin used that flags or not, and in which way. Could this be a possible cause of the errors? Anyway, it only would affect to the slice compiled files, and there are other clases with undefined Ice symbols aswell...

Hi,

Thanks for your answer. If we include these 4 flags the build process shows this error:

ld: library not found for -libc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)

If we remove the flag -libc++, the errors decrease from the 150 that XCode showed with other flags days ago, to 118. This is the aspect of the current errors:

Undefined symbols for architecture x86_64:

  "_OBJC_CLASS_$_GLACIER2RouterPrx", referenced from:
  objc-class-ref in Z41IceCommWAN.o
  "_OBJC_EHTYPE_$_GLACIER2CannotCreateSessionException", referenced from:
      GCC_except_table3 in Z41IceCommWAN.o
    (…)

  "std::string::find_last_of(char const*, unsigned long) const", referenced from:
      (anonymous namespace)::getStackTrace() in libIceObjC.a(IceUtilCpp_Exception.o)
  "std::string::find_first_of(char const*, unsigned long) const", referenced from:
      IceInternal::stringToMajorMinor(std::string const&, unsigned char&, unsigned char&) in libIceObjC.a(IceCpp_Protocol.o)
      IceInternal::Reference::toString() const in libIceObjC.a(IceCpp_Reference.o)
      IceInternal::RoutableReference::toString() const in libIceObjC.a(IceCpp_Reference.o)
      (anonymous namespace)::getStackTrace() in libIceObjC.a(IceUtilCpp_Exception.o)
      IceUtilInternal::Options::checkArgs(std::string const&, std::string const&, bool, std::string const&) in libIceObjC.a(IceUtilCpp_Options.o)
    (…)

(We are using IceTouch 1.3.3)

* Should we add any other flag ?
* Should we add any option to slice2objC or to IceBuilder rule (like —include-dir) at slice compiling process to resolve some imports problems? In which way?

Thanks a lot for your answers.

Thank you very much for your help.

We have finally built our project. We have had to provisionally remove a Test target from our XCode project, cause it produced an error at build process about derived data or not found paths, but at least the main project is working now. If you have any idea about that last issue it would be welcome. Anyway, we’re able now to continue developing.

Thanks again. Greetings from Spain.