Mavericks 3.5.1 can not talk to 3.4

ecdowney

Hello,

I am building an ICE 3.5 app on Mavericks that connects to a server on Linux Centos running ICE 3.4.2. As you recall, I was forced to use 3.5 on Mavericks because of the change to clang. Unfortunately, it appears the two protocols are incompatible, or I else am missing something (I hope).

Here is my code snippet:

// connect
        try {
            int argc = 0;
            char **argv = NULL;
            Ice::CommunicatorPtr communicator = Ice::initialize (argc, argv);
            lbto::FactoryPrx factory = lbto::FactoryPrx::checkedCast(communicator->stringToProxy(PROXY));
            if (!factory)
                bye("Can not create lbto ICE Factory");
            iif = factory->create (CLIENT_PROXY_NAME, FOCAL_STATION, INSTRUMENT_ID);
            if (!iif)
                bye("Can not create lbto ICE Proxy");

        } catch (const std::exception &e) {

            fprintf (stderr, "IFF connection exception: %s", e.what());
            return (1);

        }

and here is the build and output generated:

g++ -I../libiif -I. -I/Library/Developer/Ice-3.5.1/include -ffast-math -Wall -O2 -g -pthread -c lbtogetdd.cpp -o lbtogetdd.o
g++ -L../libiif -L/Library/Developer/Ice-3.5.1/lib/c++11 -rpath /Library/Developer/Ice-3.5.1/lib/c++11 -g -pthread -o lbtogetdd lbtogetdd.o -liif -lIce -lIceUtil -lm
clang: warning: argument unused during compilation: '-pthread'
IFF connection exception: Outgoing.cpp:499: Ice::UnknownLocalException:
unknown local exception:
/lbt/tcs_runtime/Ice-3.4.2/include/Ice/BasicStream.h:175: Ice::UnsupportedEncodingException:
protocol error: unsupported encoding version: 1.1
(can only support encodings compatible with version 1.1)
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: IceInternal::BasicStream::throwUnsupportedEncodingException(char const*, int, unsigned char, unsigned char)
  IIF: IceInternal::BasicStream::startReadEncaps()
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: Ice::Object::___ice_isA(IceInternal::Incoming&, Ice::Current const&)
  IIF: lbto::Factory::__dispatch(IceInternal::Incoming&, Ice::Current const&)
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: IceInternal::Incoming::invoke(IceInternal::Handle<IceInternal::ServantManager> const&)
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: Ice::ConnectionI::invokeAll(IceInternal::BasicStream&, int, int, unsigned char, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&)
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: Ice::ConnectionI::dispatch(IceUtil::Handle<Ice::ConnectionI::StartCallback> const&, std::vector<IceInternal::Handle<IceInternal::OutgoingAsyncMessageCallback>, std::allocator<IceInternal::Handle<IceInternal::OutgoingAsyncMessageCallback> > > const&, unsigned char, int, int, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&, IceInternal::Handle<IceInternal::OutgoingAsync> const&, IceInternal::BasicStream&)
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: Ice::ConnectionI::message(IceInternal::ThreadPoolCurrent&)
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: IceInternal::ThreadPool::run(IceUtil::Handle<IceUtil::Thread> const&)
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIce.so.34: IceInternal::ThreadPool::EventHandlerThread::run()
  /lbt/tcs_runtime/Ice-3.4.2/lib/libIceUtil.so.34/lbt/tcs_runtime/Ice-3.4.2/lib/libIceUtil.so.34(+0x4e84f) [0xfd184f]
  /lib/libpthread.so.0() [0x9eba49]
  /lib/libc.so.6: clone()

BTW, I found I had to add the rpath linker arg, this was not required before. Is this normal to have to use both -L and -rpath now on Mavericks?


Thanks for your help.

mes

Hi,

Ice 3.5 defaults to using version 1.1 of the Ice encoding. Ice 3.4 and earlier only understand version 1.0 of the encoding, so you'll need to take extra steps to ensure an Ice 3.5 application can communicate with peers that use prior Ice versions.

If you don't need to use any of the features that require the 1.1 encoding, you can simply set the property Ice.Default.EncodingVersion=1.0 in your Ice 3.5 application.

Regards,
Mark

ecdowney

Hi Mark,

Thanks for the quick reply, it sounds encouraging, but I'm not sure how to set a Property. If we can set it in our master .ice file that should cover it once and for all, otherwise it sounds like something I need to add to my c++ code. Either way, a complete example for both techniques would be most appreciated. I tried to read the docs for setting properties but I don't quite follow. Thanks.

ecdowney

Oh, and what about -rpath and -L? Thanks.

mes

The Properties and Configuration chapter of the manual describes how to use properties. There are a number of ways you can set properties:

• On the command line
• In an external configuration file
• Programmatically prior to initializing a communicator

In the sample code you posted, you're passing argc/argv to initialize, so as a temporary measure you could just pass the argument --Ice.Default.EncodingVersion=1.0 when starting your Ice 3.5 application.

The Setting Properties page provides an example of setting properties in your code.

Regards,
Mark

ecdowney

Got it! The following code now lets my Mac program talk to the Centos system:

            Ice::PropertiesPtr props = Ice::createProperties(argc, argv);
            props->setProperty("Ice.Default.EncodingVersion", "1.0");
            Ice::InitializationData id;
            id.properties = props;
            Ice::CommunicatorPtr communicator = Ice::initialize (id);

Thanks so much.

Psst: still curious about rpath

xdm

Oh, and what about -rpath and -L? Thanks.

-L options is for linker to be able to locate the libraries, it has not utility at runtime.

Ice 3.5 libraries use @rpath in the install names as the library prefix, so when you use -rpath option you are telling the executable where to find the libraries at runtime.

See rpath notes in Using the OS X Binary Distribution - Ice 3.5 - ZeroC

ecdowney

xdm wrote: »

-L options is for linker to be able to locate the libraries, it has not utility at runtime.

Ice 3.5 libraries use @rpath in the install names as the library prefix, so when you use -rpath option you are telling the executable where to find the libraries at runtime.

See rpath notes in Using the OS X Binary Distribution - Ice 3.5 - ZeroC

Ok, sounds like I need both -L and rpath now, just surprised because I didn't need rpath before switching to Mavericks and Ice 3.5.

Thanks for the great support.

xdm

In previous versions you do not need rpath, because we hardcode the default installation path in the library install name, if you want to use another path you need to change the locations of libraries embedded in the generated executables (Your application) using otool or similar tools.

With the use of rpath is up to the application developer where the Ice libraries will reside at runtime, say you want to ship the Ice libraries with you application Frameworks directory. You can use rpath = @executable_path/../Frameworks/ and copy Ice libraries in there. @executalbe_path will be expanded to the executable directory typically MyApp.app/Contents/MacOS

And you application layout will look like:

MyApp.app/Contents/MacOS/MyApp
MyApp.app/Contents/Frameworks/libIceUtil.35.dylib
MyApp.app/Contents/Frameworks/libIce.35.dylib