On 11/ 7/11 09:21 AM, Ali Bahrami wrote:
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?
No. I note that the 32 and 64 bit versions of these 11 binaries were
being built correctly under .../components/imagemagick/build before
I made the changes to the .p5m file.
I'm still trying to understand why this now works.
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?
Good questions. I'm happy to fix this with whatever is the preferred approach.
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
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
