kirchner@umn-cs.cs.umn.edu (Roger B. Kirchner) (01/02/91)
The developer release note for 2.0, OperatingSystem.rtf, contains the following: The following incompatible changes have been made to the operating system since Release 1.0. libc.a is not shipped with release 2.0. All routines contained in libc.a are also contained in the shared library libsys.a which should be used instead of libc.a. libc.a is not shipped because as a normal archive it is impossible for improvements and system interface changes made to library routines to be applicable to existing applications without those applications being relinked. Applications referencing shared libraries, because they are bound at runtime, always access the most recent release. Release 1.0 applications linked against libc.a may not be compatible with release 2.0 until they are relinked with libsys.a.
louie@sayshell.umd.edu (Louis A. Mamakos) (01/02/91)
In article <1991Jan2.125711.6400@cs.umn.edu> kirchner@umn-cs.cs.umn.edu (Roger B. Kirchner) writes: >libc.a is not shipped with release 2.0. All routines contained in >libc.a are also contained in the shared library libsys.a which should >be used instead of libc.a. It's too bad they didn't just rename libsys.a to libc.a and be done with it. That way people won't have to diddle various makefiles that have an explicit '-lc' on the linker invokation. louie
rca@cs.brown.edu (Ronald C.F. Antony) (01/03/91)
In article <1991Jan2.142229.27450@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: #In article <1991Jan2.125711.6400@cs.umn.edu> kirchner@umn-cs.cs.umn.edu (Roger B. Kirchner) writes: ##libc.a is not shipped with release 2.0. All routines contained in ##libc.a are also contained in the shared library libsys.a which should ##be used instead of libc.a. #It's too bad they didn't just rename libsys.a to libc.a and be done with it. #That way people won't have to diddle various makefiles that have an explicit #'-lc' on the linker invokation. Why not just make a link from libsys.a to libc.a? Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet
eps@toaster.SFSU.EDU (Eric P. Scott) (01/03/91)
I don't mind having the shared library pulled in by default--99+% of the time it's what you want. HOWEVER, there has to be some way of making staticly linked executables for "anything that would belong in /bin" or it's impossible to build small bootable media or chroot()ed environments. The kernel traps aren't going to change (i.e. all of man 2 is "safe"), and nearly everything else from BSD isn't likely to change (or at least not in a way that breaks anything). If NeXT changes the interfaces to netinfo, the format of Mach-O files, or adds new signals or error codes, there might be problems. The only part of libc.a in 1.0a that "needs replacement" is the BIND resolver routines. I can live with relinking for each major software revision. (Did none of the beta sites catch this???) -=EPS=-