Anyone like to review this?
Thanks.
-------- Original Message --------
Subject: Re: [userland-discuss] Code review request for CR #6857103
Date: Fri, 23 Dec 2011 10:22:44 -0800
From: Rich Burridge <rich.burri...@oracle.com>
To: Alan Coopersmith <alan.coopersm...@oracle.com>
CC: Userland-Discuss <userland-discuss@opensolaris.org>
On 12/23/2011 09:20 AM, Alan Coopersmith wrote:
On 12/23/11 03:52, Rich Burridge wrote:
Alan Coopersmith also suggested:
"My quick guess at the cleanest fix would be to move the 32-bit
version to the
i86 subdirectory and then make /usr/bin/tclsh8.5 a link to
amd64/tclsh8.5
or sparcv9/tcls8.5. (I'm guessing there are times you might want the
32-bit
version, especially if you have loadable .so modules that may be
loaded for
extensions that haven't been ported to 64-bit yet. Otherwise you'd just
drop the 32-bit and move the 64-bit into the main directory, like we
did with
the Xorg binary after the 32-bit EOF.) "
I suggested that over isaexec, since on Solaris 11, where there are
only 64-bit
kernels, isaexec is just an additional chunk of code that results in
always
running the 64-bit binary. (Unless you have more binary flavors,
such as ones
explicitly tuned for sun4u vs sun4v or something - isaexec can support
more
complex choices than just 32-bit vs. 64-bit, but I don't know of
anywhere in the
OS we've done that.)
We didn't get all the existing isaexec usage in the WOS removed after
the 32-bit
kernel EOF - perhaps another bug should be filed to make Userland
consistent and
non-isaexec'ed in all the areas that ship 32-bit& 64-bit versions
still, or to
drop 32-bit versions where both are shipped and only one is needed
(like top).
Of course that means downstream projects like OpenIndiana& other
distros which
still support 32-bit kernels have to patch in isaexec on their own,
but this
wouldn't be the first time they've had to compensate for the 32-bit
EOF in the
bits we still share.
If Mike is planning to fix top by removing the isaexec link, then it looks
like your approach is the preferred one.
So here's variant #2 (based on your first suggestion of also including
the 32 bit version):
http://jurassic.us.oracle.com/~richb/6857103-v2/
The package has been reinstalled in the test-6857103 BE mounted at /mnt
on stard.us.oracle.com.
Thanks.
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
--- Begin Message ---
Hi,
Could I please get a code review for my fix for:
6857103 tclsh should use 64bit binary on 64bit systems
http://monaco.us.oracle.com/detail.jsf?cr=6857103
Webrev is at:
http://jurassic.us.oracle.com/~richb/6857103-v1/
x86 workspace (with tcl built) is at:
/net/stard.us.oracle.com/tank/ws/UL/6857103/
Configure/build/install/publish transcript at:
/net/stard.us.oracle.com/tank/ws/UL/6857103/components/tcl/tcl/publish-trans.txt
There are several ways this could be changed. I took the approach
found in the top.p5m file.
Alan Coopersmith also suggested:
"My quick guess at the cleanest fix would be to move the 32-bit
version to the
i86 subdirectory and then make /usr/bin/tclsh8.5 a link to amd64/tclsh8.5
or sparcv9/tcls8.5. (I'm guessing there are times you might want the
32-bit
version, especially if you have loadable .so modules that may be
loaded for
extensions that haven't been ported to 64-bit yet. Otherwise you'd just
drop the 32-bit and move the 64-bit into the main directory, like we
did with
the Xorg binary after the 32-bit EOF.) "
If either of those two solutions is the preferred one, let me know
and I'll adjust accordingly.
See the Bugster CR for more details.
(Note I haven't updated the bug report yet until we have reached a
concensus on the best way of fixing this.)
Tested with:
$ sudo pkg set-publisher -p file:///tank/ws/UL/6857103/i386/repo
$ sudo beadm create test-6857103
$ sudo beadm mount test-6857103 /mnt
$ sudo pkg -R /mnt uninstall pkg://solaris/entire
$ sudo pkg -R /mnt uninstall
pkg://solaris/consolidation/userland/userland-incorporation
$ sudo pkg -R /mnt install pkg://userland/runtime/tcl-8
and then checking that the tclsh[8.5] binaries and links are correct.
That BE is currently still mounted on stard.us.oracle.com if anybody
wants to take a look.
Thanks.
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
--- End Message ---
--- Begin Message ---
On 12/23/11 03:52, Rich Burridge wrote:
Alan Coopersmith also suggested:
"My quick guess at the cleanest fix would be to move the 32-bit version to the
i86 subdirectory and then make /usr/bin/tclsh8.5 a link to amd64/tclsh8.5
or sparcv9/tcls8.5. (I'm guessing there are times you might want the 32-bit
version, especially if you have loadable .so modules that may be loaded for
extensions that haven't been ported to 64-bit yet. Otherwise you'd just
drop the 32-bit and move the 64-bit into the main directory, like we did with
the Xorg binary after the 32-bit EOF.) "
I suggested that over isaexec, since on Solaris 11, where there are only 64-bit
kernels, isaexec is just an additional chunk of code that results in always
running the 64-bit binary. (Unless you have more binary flavors, such as ones
explicitly tuned for sun4u vs sun4v or something - isaexec can support more
complex choices than just 32-bit vs. 64-bit, but I don't know of anywhere in the
OS we've done that.)
We didn't get all the existing isaexec usage in the WOS removed after the 32-bit
kernel EOF - perhaps another bug should be filed to make Userland consistent and
non-isaexec'ed in all the areas that ship 32-bit & 64-bit versions still, or to
drop 32-bit versions where both are shipped and only one is needed (like top).
Of course that means downstream projects like OpenIndiana & other distros which
still support 32-bit kernels have to patch in isaexec on their own, but this
wouldn't be the first time they've had to compensate for the 32-bit EOF in the
bits we still share.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
--- End Message ---
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
