Le Mon, Aug 15, 2011 at 05:16:44PM +0100, Simon McVittie a écrit : > > m2crypto appears to have regressed between 0.20.1-1.1 and 0.21.1-1: > > > smcv@reptile(sid-amd64)% python2.6 -c 'import M2Crypto' > > Traceback (most recent call last): > > File "<string>", line 1, in <module> > > File "/usr/lib/python2.6/dist-packages/M2Crypto/__init__.py", line 22, in > > <module> > > import __m2crypto > > ImportError: /usr/lib/python2.6/dist-packages/M2Crypto/__m2crypto.so: > > undefined symbol: SSLv2_method > > The amd64 binaries were the ones uploaded by the maintainer, but buildd logs > for a couple of arbitrarily-chosen architectures (i386 and s390) suggest that > this is a general problem with the package, not just a problem with the > maintainer's build environment: > > > SWIG/_m2crypto_wrap.c: In function '_wrap_sslv2_method': > > SWIG/_m2crypto_wrap.c:15485:3: warning: implicit declaration of function > > 'SSLv2_method' [-Wimplicit-function-declaration] > > Because the file in question is a Python module (basically a plugin), > unresolvable symbols do not cause the build to fail.
Thank you very much Simon and Sébastien for your help. I have built the amd64 version of the package in a clean Sid chroot with sbuild, and I indeed did not understand the compiler warnings. The problem should be solved now that I re-enabled Sebastian's patch, that I did not realise was not part from revision 721 in Upstream's Subversion repository. As you can see from the commit diff below (I keep the build logs in the same Git repository as the source package), the compiler warnings dissapeared as expected. http://anonscm.debian.org/gitweb/?p=collab-maint/m2crypto.git;a=commitdiff;h=3a906d75c341b97ba5cc03af76d535173b07cc4b#patch2 I tested python-m2crypto version 0.21.1-1 on my local system, which is a mixture of Squeeze, Wheezy and Sid where libssl1.0.0 and libssl0.9.8 are installed. Given that the module was working well, as per successful use of the euca2ools programs that use it, and given that the regression tests were failing for lack of SSLv2 support, I thought that I successfully tested it against libssl1.0.0, the OpenSSL library the package was built on depends on. Have I misunderstood how dynamic libraries are used, or is it indeed a bug that a package depending on libssl1.0.0 seems to be using libssl0.9.8 when they are co-installed ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
