On Tue, 2008-05-13 at 14:07 -0700, Mike Sullivan wrote:
>
> {mike_s:yavin:1001} pwd
> /ws/sfwnv-gate/proto/root_sparc/usr/lib/python2.4/vendor-packages/64
> {mike_s:yavin:1002} ls
> cups.so* libxml2mod.so*
> {mike_s:yavin:1003} file *.so
> cups.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
> dynamically linked, not stripped, no debugging information available
> libxml2mod.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
> dynamically linked, not stripped, no debugging information available
>
> (unless I misread). It may have come in with
>
> 6598832 need 64-bit Python libxml bindings
>
> (though it's hard to tell with all the merge deltas in Targetdirs,
> whoops). Though it's probably not quite right as it's a directory,
> and usually what we do is have the 64-bit arch there with 64 as a
> link to it, like 64->amd64, though I don't remember why we did that.
> But it looks like everything else does.
Unless there's a good reason to change the 64/ dirs to amd64|sparcv9
I suggest we leave them. The way we implemented 64-bit support
in Python creates a 64/ subdir for the 64-bit shared objects.
SUNWPython itself delivers its 64-bit objects in 64/.
If we wanted to change it to be a symlink, we would have to
do that in SUNWPython first.
Laca
