On 11/07/11 10:04, Danek Duvall wrote:
Rich Burridge wrote:
http://jurassic.us.oracle.com/~richb/7087597-v1/
I don't see how this addresses the problem. /usr/bin/animate (for
instance) is built with an incorrect RUNPATH for a 32-bit executable.
Danek
That was my first thought too, as this simply adds 64-bit
binaries. However, assuming I'm looking at the right binary,
the 32-bit paths might have been fixed too, though the webrev
does not show how:
elfdump -d
/net/stard.us.oracle.com/tank/ws/UL/7087597/components/imagemagick/build/i86/utilities/.libs/animate
| grep PATH
[7] RUNPATH 0x258 /usr/lib
[8] RPATH 0x258 /usr/lib
Is the webrev missing a file?
In addition to Danek's question, I'd like to ask how the user will
know about these 64-bit versions. It's great that they're there, but
they're not in anyones PATH.
In the past, we would have put the 32 and 64-bit versions down in
the per-platform directories, and used an isaexec link at the usr/bin
level. Now that there's no 32-bit kernel, it's also possible to
dispense with the 32-bit versions entirely and install the 64-bit
in usr/bin directly. Do we really need or want to deliver this as
both 32 and 64-bit?
Note that I eliminated the 32-bit versions of emacs in my last
maintenance for that package on similar grounds, hence my interest.
Thanks...
- Ali
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
