Re: pkg/44580: python26: PLIST issue on OpenSolaris

["Filip Hajny" <filip%joyent.com@localhost>]

On 15.2.2011, at 20:20, cheusov%tut.by@localhost wrote:

> Building lang/python26 ends like the following.
> 
>   => Creating binary package /srv/pkgsrc_bin/SunOS/All/python26-2.6.6nb5.tgz
>   pkg_create: can't stat 
> `/tmp/obj-pkgsrc/lang/python26/work/.destdir/usr/pkg/lib/python2.6/lib-dynload/_ctypes.so'
>   pkg_create: can't stat 
> `/tmp/obj-pkgsrc/lang/python26/work/.destdir/usr/pkg/lib/python2.6/lib-dynload/_socket.so'
>   pkg_create: can't stat 
> `/tmp/obj-pkgsrc/lang/python26/work/.destdir/usr/pkg/lib/python2.6/lib-dynload/_ssl.so'
>   pkg_create: lstat failed for file lib/python2.6/lib-dynload/_ctypes.so: No 
> such file or directory
>   *** Error code 2

This is not a PLIST issue, well at least unless you're fine with having a 
ctype-less Python installation.

The problem is not in lang/python26, but in devel/libffi (which ctypes 
requires). I have been able to build lang/python26 with Studio and ABI=64, 
provided I use a GCC-compiled devel/libffi package. The general consensus seems 
to be that libffi simply requires GCC.

However even with GCC, libffi fails with ABI=64 on Solaris in a nasty way - it 
builds a valid 64bit shared lib that doesn't include the source required to 
make it anything useful on x86_64 (something that ctypes will be happy with). I 
have yet to turn this into a proper patch (not sure when I'll have time for 
that), and it's a case for upstream fixing for sure.

-F