W: dh_python2:427: public extension linked with libpython2.7: libvtkgdcmPython.so
[CC me please] Hi there, I am looking for more information about [1] and [2]. Here is my current issue. GDCM ships a python module which in turn links to a shared libs. It looks like this: $ readelf -d /usr/lib/pyshared/python2.7/libvtkgdcmPython.so Dynamic section at offset 0x1de0 contains 26 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libvtkgdcmPythonD.so.2.2] 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libc.so.6] As one can see above, there is no *explicit* linking to libpythonX.Y.so as per python module policy in debian. However it turns nasty when one look at libvtkgdcmPythonD.so.2.2: $ readelf -d /usr/lib/libvtkgdcmPythonD.so.2.2 Dynamic section at offset 0x37d38 contains 34 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libvtkgdcm.so.2.2] 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0] 0x0001 (NEEDED) Shared library: [libvtkCommonPythonD.so.5.8] 0x0001 (NEEDED) Shared library: [libvtkIOPythonD.so.5.8] 0x0001 (NEEDED) Shared library: [libvtkImagingPythonD.so.5.8] 0x0001 (NEEDED) Shared library: [libvtkFilteringPythonD.so.5.8] 0x0001 (NEEDED) Shared library: [libvtkPythonCore.so.5.8] 0x0001 (NEEDED) Shared library: [libvtkCommon.so.5.8] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000e (SONAME) Library soname: [libvtkgdcmPythonD.so.2.2] dh_python2 is obviously looking into transitive linking and reports that libvtkgdcmPython.so actually links to libpython2.7.so.1.0 which is a illegal as per policy. Reading the policy this is not clear how bad this linking is. What are the possible issues in doing so ? Please note that, I cannot simply remove the linking to libpython2.7.so.1.0, since libvtkgdcmPythonD.so.2.2 is a shared lib and thus required full resolution of all symbols including those: $ nm -D /usr/lib/libvtkgdcmPythonD.so.2.2 U PyFloat_FromDouble U PyInt_FromLong U PyLong_FromLongLong U PyLong_FromUnsignedLong U PyString_FromString U Py_FatalError U Py_InitModule4_64 U _Py_NoneStruct does anyone in which case this could be causing some troubles ? multi-arch python install ? multi-python installation ?... thanks much for inputs ! [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html [2] http://bugs.debian.org/592414 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUsxRnok5JQpHHbS=pkwu5yepbjskb0807hdzbdu0ze1...@mail.gmail.com
Re: W: dh_python2:427: public extension linked with libpython2.7: libvtkgdcmPython.so
On Tue, May 8, 2012 at 9:28 AM, Mathieu Malaterre wrote: ... > $ readelf -d /usr/lib/pyshared/python2.7/libvtkgdcmPython.so > > Dynamic section at offset 0x1de0 contains 26 entries: > Tag Type Name/Value > 0x0001 (NEEDED) Shared library: > [libvtkgdcmPythonD.so.2.2] > 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0] I actually did not realize cmake would put on the link line any dependant shared libs. Therefore the module *itself* ended up being link explicitely to the libpython2.7.so... I fixed this with the proper cmake incantation. Sorry for the noise, -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUsxLDJj5=-kpuom1benzrcjib6n3a2dhs6ofvczp_wf...@mail.gmail.com
Re: Packaging python-mocker and cloud-init in Debian ?
Le Sat, May 05, 2012 at 01:29:24PM -0400, Scott Moser a écrit : > On Sat, 5 May 2012, Charles Plessy wrote: > > > I think that your proposition to separate grub-legacy-ec2 is good, > > especially > > that in Debian, the plan is to maintain cloud-init in the python > > applications > > packaging team, and grub-legacy-ec2 has nothing to do with Python. > > > > It looks like ideally, the functions of grub-legacy-ec2 could be attached to > > the grub2 package so that they can share their configuration. How about if > > I > > contact the grub2 maintainers and tell about the need to create menu.lst in > > pv-grub-booted systems, proposing grub-legacy-ec2's code as a starting > > point ? > > I think that sounds like a good idea. Hi again, I proposed the idea to the grub2 maintainers in http://bugs.debian.org/672104. In the meantime, I consider uploading a version of cloud-init where grub-legacy-ec2 and all the diversions have been removed. Would this make your work hader in Ubuntu ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120509044935.ge...@falafel.plessy.net
