Archived
This forum has been archived. Please start a new discussion on GitHub.
Mavericks 3.5.1 can not talk to 3.4
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:
and here is the build and output generated:
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.
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.
0
Comments
-
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,
Mark0 -
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.0 -
Oh, and what about -rpath and -L? Thanks.0
-
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
The Setting Properties page provides an example of setting properties in your code.
Regards,
Mark0 -
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 rpath0 -
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 - ZeroC0 -
-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.0 -
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
0