Indeed setting -DSWIGEXPORT=__global solves the issue because SWIG doesn't define the export symbol equivalent for Solaris.
Issue created and patch attached: https://issues.apache.org/jira/browse/PROTON-1392 Regards, Adel ________________________________ From: Ken Giusti <[email protected]> Sent: Wednesday, January 18, 2017 5:35:43 PM To: [email protected] Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is failing in the python tests ----- Original Message ----- > From: "Adel Boutros" <[email protected]> > To: [email protected] > Sent: Wednesday, January 18, 2017 5:18:41 AM > Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is > failing in the python tests > > Hello, > > > We found the issue!! > Nice! > > The symbol is actually present however in cmake, you set the visibility by > default to hidden (Linux: -fvisibility=hidden | Solaris: -xldscoe=hidden). > So the _cproton.so contained the symbol but only available locally not > globally. This can be verified using nm. > > > I don't know why it is working with GCC on Linux but probably because he > doesn't care about the scope whereas Solaris (cc) does. > Try poking around in the swig-generated C code (cprotonPYTHON_wrap.c) - in there I see swig is generating the proper pragmas to 'unhide' the init_cproton function for GNU C and WIN32. If I'm correct swig doesn't generate such pragmas for Solaris. >From my cprotonPYTHON_wrap.c on linux: ..... /* exporting methods */ #if (__GNUC__ >= 4) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) # ifndef GCC_HASCLASSVISIBILITY # define GCC_HASCLASSVISIBILITY # endif #endif #ifndef SWIGEXPORT # if defined(_WIN32) || defined(__WIN32__) || defined(__CYGWIN__) # if defined(STATIC_LINKED) # define SWIGEXPORT # else # define SWIGEXPORT __declspec(dllexport) # endif # else # if defined(__GNUC__) && defined(GCC_HASCLASSVISIBILITY) # define SWIGEXPORT __attribute__ ((visibility("default"))) # else # define SWIGEXPORT # endif # endif #endif ..... > > As a workaround, I override the CMAKE_C_FLAGS in > proton-c/bindings/python/CMakeLists.txt to have -xldscoe=global. > > > The workaround is working perfectly and Python is able to load "_cproton.so". > > > However, I don't know if this a proper fix or not and I would be more than > happy to provide a patch for this. > As an alternative (totally untested) conditionally add a -DSWIGEXPORT=<blah> to the CMAKE_C_FLAGS where <blah> is whatever pragma your compiler uses to unhide declarations. In any case it would be most welcome if you'd like to open a JIRA and add your patch to that. thanks, -K > > Regards, > > Adel > > ________________________________ > From: Adel Boutros <[email protected]> > Sent: Tuesday, January 17, 2017 6:46:56 PM > To: [email protected] > Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is > failing in the python tests > > I changed cproton.i to have nothing in it and I am still experiencing the > issue. > > > I honestly think it is a compiler issue as you said. I will try to use a > different compiler or try to have a simpler "hello world" in swig and test > it. > > Hopefully I will find something otherwise I am stuck :( > > > Regards, > > Adel > > ________________________________ > From: Ken Giusti <[email protected]> > Sent: Tuesday, January 17, 2017 6:33:59 PM > To: [email protected] > Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is > failing in the python tests > > Adel, > > Seems like the root cause of the problem you're hitting is different than > what I hit - in my case the imported proton module was incorrectly loading > the py3 shared object (which defines PyInit_cproton, not init_cproton). > > But what you seem to be experiencing is different - you've confirmed that > you're loading the module under python 2, and the module is pulling in the > correct _cproton.so, and that _cproton.so actually _does_ export the > init_cproton entry point. > > I'm stumped. Seems almost like a problem with the linker - the correct .so > was found, the symbol is there, but the dynamic linker isn't resolving it. > > I don't have access to a solaris box, unfortunately. > > -K > > ----- Original Message ----- > > From: "Adel Boutros" <[email protected]> > > To: [email protected] > > Sent: Tuesday, January 17, 2017 10:33:53 AM > > Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is > > failing in the python tests > > > > Hello Ken, > > > > > > Based on your reply, I did some investigation. I modified cproton.i to > > detect > > what version of python is used and I confirmed it is using Python < 3 > > > > > > cproton.i > > > > ----------------- > > > > #if PY_VERSION_HEX >= 0x03000000 > > #else > > #error Unsupported choice setting > > #endif > > > > > > > > I hit the error "Unsupported choice setting" when compiling. > > > > > > I also ran truss because strace was not working correctly and it is loading > > the correct _cproton.so using python 2.7.9. > > > > > > So init_cproton is generated correctly in the code and is present. > > > > > > Do you have some other advice? Could there be an #ifdef related to linux > > (if > > defined(__GNUC__)) which is not defined for Solaris or something else? > > > > > > Regards, > > > > Adel > > > > ________________________________ > > From: Ken Giusti <[email protected]> > > Sent: Monday, January 16, 2017 7:38:46 PM > > To: [email protected] > > Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is > > failing in the python tests > > > > Adel - > > > > I've hit this error before and it was due to a mix up with my library > > paths. > > > > When I got that error my 2.7 python env was trying to load the .so built > > using the python3 library. > > > > Can you run strace on the test to see exactly which _cproton.so is being > > loaded? > > > > -K > > > > > > ----- Original Message ----- > > > From: "Adel Boutros" <[email protected]> > > > To: [email protected] > > > Sent: Monday, January 16, 2017 1:28:36 PM > > > Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris > > > is > > > failing in the python tests > > > > > > I just compiled SWIG 1.3.40 on Solaris and tried but still got the same > > > error > > > :( > > > > > > ________________________________ > > > From: Adel Boutros <[email protected]> > > > Sent: Monday, January 16, 2017 7:00:41 PM > > > To: [email protected] > > > Subject: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is > > > failing in the python tests > > > > > > Hello, > > > > > > > > > I am actually trying to activate the python bindings in Proton so I can > > > compile Dispatch Router on Solaris. However, the python unit tests of > > > Proton > > > are failing. > > > > > > Cmake Configuration > > > > > > ---------------------------- > > > > > > Found PythonInterp: ..../bin/python (found version "2.7.9") > > > Found SWIG: ..../bin/swig (found version "2.0.9") > > > Found CyrusSASL: ..../lib/64/libsasl2.so > > > Found PythonLibs: ..../libpython2.7.so (found suitable exact version > > > "2.7.9") > > > Could NOT find Ruby (missing: RUBY_EXECUTABLE RUBY_INCLUDE_DIR > > > RUBY_LIBRARY) > > > > > > > > > Error (tests/python/proton-test) > > > > > > --------------------- > > > > > > 1: File "..../build-dir/proton/proton-c/bindings/python/cproton.py", > > > line > > > 22, in swig_import_helper > > > 1: _mod = imp.load_module('_cproton', fp, pathname, description) > > > 1: ImportError: dynamic module does not define init function > > > (init_cproton) > > > > > > > > > Analysis > > > > > > -------------------- > > > > > > Listing symbols in _cproton.so shows the above function is available > > > > > > nm _cproton.so | grep init_cproton > > > [62] | 340924| 5677|FUNC |LOCL |2 |13 > > > |init_cproton > > > > > > > > > I suspect SWIG version (2.0.9) to be the culprit however I am not pretty > > > sure > > > if it related. On Linux, I am using SWIG version 1.3.40 and it is > > > working. > > > > > > I am actually out of ideas. So any help is highly appreciated! > > > > > > > > > PS: I am compiling in 64-bit mode in case it helps. > > > > > > > > > Regards, > > > > > > Adel > > > > > > > -- > > -K > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > -K > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
