This announcement applies only to 32-bit static system libraries and statically linked utilites. 64-bit static system libraries and utilities have never been provided.
The Solaris Application Binary Interface (ABI) is provided through dynamic system libraries. All Solaris applications should be linked with the Solaris dynamic system libraries. 32-bit applications linked with Solaris static system libraries do not utilize the Solaris ABI.
Support for 32-bit Solaris static system libraries and statically linked utilities will not be provided in a future release. Of particular note, support for the static C library (/usr/lib/libc.a) will not be provided in a future release.
Please send feedback/comments to: static-libs-feedb...@sun.com
> Support for 32-bit Solaris static system libraries and statically > linked utilities will not be provided in a future release. Of > particular note, support for the static C library (/usr/lib/libc.a) > will not be provided in a future release.
I'm all for losing the static libraries, but I think that the statically linked binaries (currently in /usr/sbin/static) should be kept - you never know when they will be handy. In fact, they've saved my skin at least once.
Actually, if anything, those binaries should be moved to /sbin/static, to be of use to people who insist on using a separate /usr partition.
In summary:
1. Lose the static libraries as planned
2. Move the static binaries in /usr/sbin/static to /sbin/static
In comp.unix.solaris Rich Teer <r...@rite-group.com> wrote:
> On 31 Oct 2002, John Barton wrote: >> Support for 32-bit Solaris static system libraries and statically >> linked utilities will not be provided in a future release. Of >> particular note, support for the static C library (/usr/lib/libc.a) >> will not be provided in a future release. > I'm all for losing the static libraries, but I think that > the statically linked binaries (currently in /usr/sbin/static) > should be kept - you never know when they will be handy. > In fact, they've saved my skin at least once. > Actually, if anything, those binaries should be moved to > /sbin/static, to be of use to people who insist on using a > separate /usr partition. > In summary: > 1. Lose the static libraries as planned > 2. Move the static binaries in /usr/sbin/static to /sbin/static
But.. how can Sun continue supporting the static binaries if they will discontinue support for static libraries?
>>> particular note, support for the static C library (/usr/lib/libc.a) >>> will not be provided in a future release.
>> I'm all for losing the static libraries, but I think that >> the statically linked binaries (currently in /usr/sbin/static) >> should be kept - you never know when they will be handy. >> In fact, they've saved my skin at least once.
>> Actually, if anything, those binaries should be moved to >> /sbin/static, to be of use to people who insist on using a >> separate /usr partition.
>> In summary:
>> 1. Lose the static libraries as planned
>> 2. Move the static binaries in /usr/sbin/static to /sbin/static
> But.. how can Sun continue supporting the static binaries if they will > discontinue support for static libraries?
Heh! Neither one of you is reading the article ;-)
It looks like /usr better be on the / partition from that point on.
On Fri, 1 Nov 2002, Akop Pogosian wrote: > But.. how can Sun continue supporting the static binaries if they will > discontinue support for static libraries?
Sun has the full source code. What they use internally, and what they make available externally don't necessarily have to be the same thing...
* Rich Teer wrote: > Sun has the full source code. What they use internally, > and what they make available externally don't necessarily > have to be the same thing...
However, it would be nice if a user of the system can *also* construct static binaries, if needed.
In article <ey3hef1vbed....@cley.com>, Tim Bradshaw <t...@cley.com> wrote:
>* Rich Teer wrote:
>> Sun has the full source code. What they use internally, >> and what they make available externally don't necessarily >> have to be the same thing...
>However, it would be nice if a user of the system can *also* construct >static binaries, if needed.
Would you be willing to live with the caveat that they would have to be relinked any time a library patch is installed or the OS is upgraded? Maintaining upward compatibility of the library API is relatively easy; maintaining binary compatibility is much harder, and may limit what the vendor can do to fix bugs.
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> Would you be willing to live with the caveat that they would have to be > relinked any time a library patch is installed or the OS is upgraded? > Maintaining upward compatibility of the library API is relatively easy; > maintaining binary compatibility is much harder, and may limit what the > vendor can do to fix bugs.
I don't really understand this. If a binary is statically linked, then surely the only calls it makes are system calls? I don't think they get changed all the time. Sure, if it uses a lot of libraries that do stuff which exchange data whose format might change (so IPC of whatever kind) hidden behind a library, then it might lose, but how common is that?
In fact, in the early days of what is now xemacs (then lemacs) I remember that a lot of the binary distributions that got made were statically linked, because that way you only depended on low-level stuff like the X protocol and system calls, not which of the 983 versions of some random library happened to be installed on the target machine. This was done because there was *so* much trouble from dynamic binaries that just wouldn't run.
*However* it looks (from reading the original article) as if Sun are intending to not provide any static binaries at all, not even /sbin/sh (say). My real issue is that I don't want there to be (too many) magic things that Sun can produce (static binaries) which I can't.
Tim Bradshaw <t...@cley.com> writes: >I don't really understand this. If a binary is statically linked, >then surely the only calls it makes are system calls? I don't think >they get changed all the time. Sure, if it uses a lot of libraries >that do stuff which exchange data whose format might change (so IPC of >whatever kind) hidden behind a library, then it might lose, but how >common is that?
They do get changed some of the time; some system calls are added; others have been removed or changed, sometimes in incompatible ways.
>*However* it looks (from reading the original article) as if Sun are >intending to not provide any static binaries at all, not even /sbin/sh >(say). My real issue is that I don't want there to be (too many) >magic things that Sun can produce (static binaries) which I can't.
No static binaries, correct.
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
>>I don't really understand this. If a binary is statically linked, >>then surely the only calls it makes are system calls? I don't think >>they get changed all the time. Sure, if it uses a lot of libraries >>that do stuff which exchange data whose format might change (so IPC of >>whatever kind) hidden behind a library, then it might lose, but how >>common is that?
>They do get changed some of the time; some system calls are added; >others have been removed or changed, sometimes in incompatible ways.
Like when the socket API was changed from system calls to Streams-based library functions.
These types of incompatible changes at the binary level are probably pretty infrequent in patches, but I'll bet there are a few of them during each major release of the OS.
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> Tim Bradshaw <t...@cley.com> writes: >>*However* it looks (from reading the original article) as if Sun are >>intending to not provide any static binaries at all, not even /sbin/sh >>(say). My real issue is that I don't want there to be (too many) >>magic things that Sun can produce (static binaries) which I can't.
> No static binaries, correct.
So does that include /sbin/mount? Does that mean that /usr cannot be on a separate (and possibly read-only) partition?
In article <20f68642.0210311326.dbad...@posting.google.com>, john.bar...@sun.com says...
> Statement of Direction
> This announcement applies only to 32-bit static system libraries and > statically linked utilites. 64-bit static system libraries and > utilities have never been provided.
> The Solaris Application Binary Interface (ABI) is provided through > dynamic system libraries. All Solaris applications should be linked > with the Solaris dynamic system libraries. 32-bit applications linked > with Solaris static system libraries do not utilize the Solaris ABI.
> Support for 32-bit Solaris static system libraries and statically > linked utilities will not be provided in a future release. Of > particular note, support for the static C library (/usr/lib/libc.a) > will not be provided in a future release.
Why? What, exactly, is the problem with the static libs? So the static 32-bit apps don't use the Solaris ABI, who cares. Get too restrictive and try to force everybody into the "Sun way" and you'll start to drop to the dark depths of Microsoft.
grog <g...@oo.r> writes: >Why? What, exactly, is the problem with the static libs? So the static >32-bit apps don't use the Solaris ABI, who cares. Get too restrictive >and try to force everybody into the "Sun way" and you'll start to drop >to the dark depths of Microsoft.
Even in the current situtation, there have been many problems with static libraries:
- linking statically against libsocket/libnsl - broken when upgrading to 2.6
- partially static linking (libc statically, lib thread not) - applications broke when the libthread/libc interfaces got upgraded
It's especially the ability to pick and chose libraries that gives no end to trouble.
And Solaris 10 adds another very good reason; it pushed the static libraries off the edge.
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
Casper H.S Dik wrote: > - partially static linking (libc statically, lib thread not) > - applications broke when the libthread/libc interfaces > got upgraded
It's been like that for years, so why did it become a problem worth solving now? Hmmm... TLS alone can't be the reason... But perhaps you're going to make dynamic loading of libthread (and thus making program "threaded" on the fly) legal and supported?
-- .-. .-. I don't work here. I'm a consultant. (_ \ / _) | d...@willfork.com |
> > Support for 32-bit Solaris static system libraries and statically > > linked utilities will not be provided in a future release. Of > > particular note, support for the static C library (/usr/lib/libc.a) > > will not be provided in a future release.
> I'm all for losing the static libraries, but I think that > the statically linked binaries (currently in /usr/sbin/static) > should be kept - you never know when they will be handy. > In fact, they've saved my skin at least once.
> Actually, if anything, those binaries should be moved to > /sbin/static, to be of use to people who insist on using a > separate /usr partition.
> In summary:
> 1. Lose the static libraries as planned
> 2. Move the static binaries in /usr/sbin/static to /sbin/static
I agree - the static binaries have saved me more than once too, as I have root mounted as its own filesystem, with /usr on another.
I do not like the idea of having to mount /root and /usr on the same filesystem. I would concede to having shared objects rather than static if there was a root mounted /lib with a subset of the necessary shared objects required to boot a system in distress and repair it.
Currently, /lib is a symlink to /usr/lib which is useless if you want to be able to boot the system and /usr is unmountable. I am, obviously of the school that doesn't like the critical filesystems all mounted under /root.
> In article > <Pine.GSO.4.44.0210311512340.15342-100...@grover.rite-group.com>, > Rich Teer <r...@rite-group.com> wrote:
>> On 31 Oct 2002, John Barton wrote:
>> > Support for 32-bit Solaris static system libraries and statically >> > linked utilities will not be provided in a future release. Of >> > particular note, support for the static C library (/usr/lib/libc.a) >> > will not be provided in a future release.
>> I'm all for losing the static libraries, but I think that >> the statically linked binaries (currently in /usr/sbin/static) >> should be kept - you never know when they will be handy. >> In fact, they've saved my skin at least once.
>> Actually, if anything, those binaries should be moved to >> /sbin/static, to be of use to people who insist on using a >> separate /usr partition.
>> In summary:
>> 1. Lose the static libraries as planned
>> 2. Move the static binaries in /usr/sbin/static to /sbin/static
> I agree - the static binaries have saved me more than once too, as I > have root mounted as its own filesystem, with /usr on another.
> I do not like the idea of having to mount /root and /usr on the same > filesystem. I would concede to having shared objects rather than static > if there was a root mounted /lib with a subset of the necessary shared > objects required to boot a system in distress and repair it.
> Currently, /lib is a symlink to /usr/lib which is useless if you want to > be able to boot the system and /usr is unmountable. I am, obviously of > the school that doesn't like the critical filesystems all mounted under > /root.
Seems a copy of libc.so.1 (albeit linked a bit differently?) in /etc/lib would take care of it. That means root needs to be about 1 MB larger. If a few more libraries were needed, that might grow to 2 MB larger. OTOH, you'd get some of that back, inasmuch as dynamically linked binaries are smaller than statically linked ones.
Under that scenario, the only greater risk I see is that a few essential statically linked binaries might be viewed as a "smaller target" to filesystem damage than similar dynamically linked binaries plus the libraries they were linked to.
In article <usap86hosn6...@corp.supernews.com>, Richard L. Hamilton <rlha...@smart.net> wrote:
>Seems a copy of libc.so.1 (albeit linked a bit differently?) in /etc/lib >would take care of it. That means root needs to be about 1 MB larger. >If a few more libraries were needed, that might grow to 2 MB larger. OTOH, >you'd get some of that back, inasmuch as dynamically linked binaries are >smaller than statically linked ones.
The only problem may be that you will not be able to replace /usr/lib/libc.so* if you neither have a static "cp", "mv" nor "tar".
OK. Looks like some folks have their undies in a bundle because of the "no static binaries" feature of Solaris ++9.
As Casper mentioned, this doesn't mean that you can't have a separate /usr partition. In the simplest case, the / partition has a /usr/lib directory in it that contains a libc.so.
Do what you want at boot time, etc. Now, mount /usr and the underlying /usr/lib is now buried below the UFS mount. What am I missing?
The question I have is what features are gained by this?
In article <3dc6ba4f$0$26649$724eb...@reader2.ash.ops.us.uu.net>, Alan Stange <sta...@rentec.com> wrote:
>OK. Looks like some folks have their undies in a bundle because of the >"no static binaries" feature of Solaris ++9.
>As Casper mentioned, this doesn't mean that you can't have a separate >/usr partition. In the simplest case, the / partition has a /usr/lib >directory in it that contains a libc.so.
>Do what you want at boot time, etc. Now, mount /usr and the underlying >/usr/lib is now buried below the UFS mount. What am I missing?
The ability to patch the root filing system versions of /usr/lib while the system is running!
There are dynamically linked binaries in /sbin that are executable before /usr is mounted in existing releases of Solaris. They use the shared libraries in /etc/lib. I expect beefing up the latter is what Sun have in mind.
In article <3dc6ba4f$0$26649$724eb...@reader2.ash.ops.us.uu.net>, Alan Stange <sta...@rentec.com> writes:
> OK. Looks like some folks have their undies in a bundle because of the > "no static binaries" feature of Solaris ++9.
> As Casper mentioned, this doesn't mean that you can't have a separate > /usr partition. In the simplest case, the / partition has a /usr/lib > directory in it that contains a libc.so.
> Do what you want at boot time, etc. Now, mount /usr and the underlying > /usr/lib is now buried below the UFS mount. What am I missing?
> The question I have is what features are gained by this?
For the end user, not much, aside from avoiding version skew given that patches to shared libc and to static libc and static binaries are rarely simultaneous. For Sun, not needing to maintain static libc and statically linked binaries, and a bit more freedom to change internals without worrying about what will break (as long as APIs/ABIs are kept consistent), which in turn reduces the cost (and overhead in obsolete code) of keeping binary compatibility.
In article <aq6e6c$kg...@pegasus.csx.cam.ac.uk>, c...@cus.cam.ac.uk (Chris Thompson) writes:
> In article <3dc6ba4f$0$26649$724eb...@reader2.ash.ops.us.uu.net>, > Alan Stange <sta...@rentec.com> wrote: [...] >>Do what you want at boot time, etc. Now, mount /usr and the underlying >>/usr/lib is now buried below the UFS mount. What am I missing?
> The ability to patch the root filing system versions of /usr/lib while > the system is running!
NFS can get at a directory hidden under a mount point. But that's something to keep in mind if one suspects a file is there that shouldn't be, not a way around your point, since it's quite impractical (and insecure, unless restricted to themselves only) to require everyone to share /.
> There are dynamically linked binaries in /sbin that are executable before > /usr is mounted in existing releases of Solaris. They use the shared > libraries in /etc/lib. I expect beefing up the latter is what Sun have > in mind.
j...@cs.tu-berlin.de (Joerg Schilling) writes: >In article <usap86hosn6...@corp.supernews.com>, >Richard L. Hamilton <rlha...@smart.net> wrote: >>Seems a copy of libc.so.1 (albeit linked a bit differently?) in /etc/lib >>would take care of it. That means root needs to be about 1 MB larger. >>If a few more libraries were needed, that might grow to 2 MB larger. OTOH, >>you'd get some of that back, inasmuch as dynamically linked binaries are >>smaller than statically linked ones. >The only problem may be that you will not be able to replace /usr/lib/libc.so* >if you neither have a static "cp", "mv" nor "tar".
Sure you can.
"ln" (ln libc.so.1 libc.so.old; ln libc.so.new libc.so.1) "cpio" (will do the rigth thing when overwriting a file; create /usr/lib/XXXXX and rename)
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
In comp.sys.sun.admin Richard L. Hamilton <rlha...@smart.net> wrote:
>For Sun, not needing to maintain static libc and statically >linked binaries, and a bit more freedom to change internals without >worrying about what will break (as long as APIs/ABIs are kept consistent), >which in turn reduces the cost (and overhead in obsolete code) of keeping >binary compatibility.
The cost of maintaining static binaries, both in developer and user hours, has been well out of proportion to their usefulness for over a decade now. Sun is just following the lead of other Unix distributions which work well without static binaries.
Good to see Solaris engineering looking ahead and eliminating more legacy-only code (though I sure miss the easy to configure Openwindows menu).
Hope the trend continues with the elimination of another needless complexity that also causes more problems than it solves: /usr partitions.
