blob: ab6650c48537fd2f3e6e9b977ec6c7a09628aca2 [file] [log] [blame]
raff808c852006-08-08 23:21:36 -07001#
4# The contents of this file are subject to the terms of the
5# Common Development and Distribution License (the "License").
6# You may not use this file except in compliance with the License.
8# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9# or
10# See the License for the specific language governing permissions
11# and limitations under the License.
13# When distributing Covered Code, include this CDDL HEADER in each
14# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
15# If applicable, add the following below this CDDL HEADER, with the
16# fields enclosed by brackets "[]" replaced with your own identifying
17# information: Portions Copyright [yyyy] [name of copyright owner]
Ali Bahramicd3e9332010-06-24 18:16:42 -060022# Copyright (c) 2006, 2010, Oracle and/or its affiliates. All rights reserved.
raff808c852006-08-08 23:21:36 -070023#
raff808c852006-08-08 23:21:36 -070024
Richard Lowe0409b952012-10-14 15:13:58 -040025Mapfiles and versioning in illumos
raff808c852006-08-08 23:21:36 -070027
281.0 Objective of this README
30This README describes the engineering practices of creating and updating
31visible library interfaces. It describes various kinds of actions that
32typically occur as libraries are evolved, and shows how interface
33specifications are affected or updated in accordance. It tells you what
34you must do as a shared library developer if you:
36 1. Make interface additions to an existing library
37 - add a Public interface
38 - add a Private interface
39 2. Update an interface in an existing library
40 - remove an existing interface
41 - promote a Private interface to Public
42 - scope a Private interface to local
43 - move an interface from one library to another
44 - copy interfaces which are part of the standard to a new or
45 existing library
46 3. Introduce a new library
47 - source directory hierarchy
48 - creation of the "mapfile-vers" file
49 - Makefiles
50 4. Make an entire library obsolete before end-of-life
51 - introduce SUNWobsolete to the "mapfile-vers" file
552.0 What's a mapfile?
Ali Bahramicd3e9332010-06-24 18:16:42 -060057Mapfiles are used to tell the link-editor ("ld") all sorts of things about
raff808c852006-08-08 23:21:36 -070058how to generate an executable file or a shared object from a collection of
59relocatable objects, such as generated by a compiler. For all the gory
Richard Lowe0409b952012-10-14 15:13:58 -040060details, see the Solaris Linker and Libraries Guide.
raff808c852006-08-08 23:21:36 -070061
Ali Bahramicd3e9332010-06-24 18:16:42 -060062There are two versions of the mapfile language accepted by the link-editor.
63Version 1 derives from AT&T System V Release 4 Unix. Version 2 is a newer
Richard Lowe0409b952012-10-14 15:13:58 -040064syntax specific to Solaris and derivatives. All mapfiles in illumos are
Ali Bahramicd3e9332010-06-24 18:16:42 -060065required to use version 2 syntax. Note that every mapfile using version 2
66syntax must start with the line:
68 $mapfile_version 2
raff808c852006-08-08 23:21:36 -070070Here, we are only concerned with specifying externally-visible interfaces
71for shared libraries (shared objects) and with specifying their versions
72for ABI (Application Binary Interface) purposes. For these purposes, we
Ali Bahramicd3e9332010-06-24 18:16:42 -060073only need to deal with a subset of the mapfile language.
raff808c852006-08-08 23:21:36 -070074
75There should be a "mapfile-vers" file associated with every shared library
76and it should reside in the common source directory for that library, most
77often in a "common" directory. This is the usual layout of a library's
78top-level directory (usr/src/lib/libwombat):
79 Makefile amd64/ i386/ sparcv9/
80 common/ sparc/
82The "common" directory contains the source files and other common files
83for the library:
84 bat.c libwombat_impl.h mapfile-vers wom.c
85 libwombat.h llib-lwombat util.c wombat.c
87The mapfile's name is, by convention, "mapfile-vers" because it is used
88for only two purposes: to specify externally-visible interface names while
89suppressing visibility of all other names, and to specify their respective
90unique version names.
943.0 Contents of mapfile-vers
96The structure of mapfile-vers is best explained by an example
97(the license notification and copyright notice is omitted here
98for brevity):
Ali Bahramicd3e9332010-06-24 18:16:42 -0600100$mapfile_version 2
Richard Lowe0409b952012-10-14 15:13:58 -0400102SYMBOL_VERSION ILLUMOS_0.2 { # Second interface change in illumos
103 global:
104 wb_notify;
105} ILLUMOS_0.1;
107SYMBOL_VERSION ILLUMOS_0.1 { # First interface change in illumos
108 global:
109 wb_poll;
110} SUNW_1.2;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600112SYMBOL_VERSION SUNW_1.2 { # update to libwombat, Solaris 10
raff808c852006-08-08 23:21:36 -0700113 global:
114 wb_readv;
115 wb_stat;
116 wb_writev;
117} SUNW_1.1;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600119SYMBOL_VERSION SUNW_1.1 { # first release of libwombat, Solaris 9
raff808c852006-08-08 23:21:36 -0700120 global:
121 wb_read;
122 wb_write;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600125SYMBOL_VERSION SUNWprivate { # private libwombat symbols
raff808c852006-08-08 23:21:36 -0700126 global:
127 wb_add;
128 wb_delete;
129 wb_search;
130 local:
131 *;
Richard Lowe0409b952012-10-14 15:13:58 -0400134Each of these sections is a version declaration describing an ABI version of
135the library containing the set of symbols exposed by the library to
136external callers.
raff808c852006-08-08 23:21:36 -0700137
Richard Lowe0409b952012-10-14 15:13:58 -0400138ABI versions must be constant, that is version ILLUMOS_0.2 in a given
139library must always describe the same interface such that applications may
140safely state their dependencies in terms of these versions and have a
141constant and predictable ABI be exposed. This in effect means that once a
142version is publicly visible, it may never be removed or have symbols added
143to or removed from it.
raff808c852006-08-08 23:21:36 -0700144
Richard Lowe0409b952012-10-14 15:13:58 -0400145ABI versions with the same major number should be upward compatible, that is
146ILLUMOS_0.3 of a given library must contain all the interfaces in
147ILLUMOS_0.2, and they must be compatible.
raff808c852006-08-08 23:21:36 -0700148
Richard Lowe0409b952012-10-14 15:13:58 -0400149The private version, however, is special, and describes any private yet
150exposed symbols within a library, and may change at any time (and without
151notice). It exists purely to allow certain symbols to be of global scope
152but not Public. Similarly, any symbols scoped local are private and may
153change safely, even if the local statement happens to be within a public
156Interface changes made in illumos should be done with ILLUMOS_0.* versions,
157introducing one version per interface change. In illumos, unlike Solaris,
158symbol versions are not release-specific because of the requirement that
159each be constant. No change should be made to add or remove symbols from
160any pre-existing Public version.
162The SUNW_*.* names were the Public version names of the library in Solaris.
163There should be at most one version name for each release of Solaris, with
164the minor number incremented by one over the previous version. No changes
165should ever be made to SUNW_1.* versions.
167So, for example, to add a new interface to libwombat in illumos one would add:
169SYMBOL_VERSION ILLUMOS_0.3 { # Third update to libwombat in illumos
raff808c852006-08-08 23:21:36 -0700170 global:
171 wb_lseek;
Richard Lowe0409b952012-10-14 15:13:58 -0400172} ILLUMOS_0.2;
raff808c852006-08-08 23:21:36 -0700173
Richard Lowe0409b952012-10-14 15:13:58 -0400174Each version must inherit all symbols from its preceding version, specified at
175the ending "}" for each version. The initial public version does not inherit
176any symbols. The private version named either "SUNWprivate" for libraries
177with private symbols pre-existing illumos, or "ILLUMOSprivate" otherwise
178stands alone, inheriting nothing and being inherited by nothing.
raff808c852006-08-08 23:21:36 -0700179
180The two lines in SUNWprivate:
181 local:
182 *;
Richard Lowe0409b952012-10-14 15:13:58 -0400183ensure that no symbols other than those listed in the mapfile are visible to
184clients of the library. If there is no private version, these two lines should
185appear in the first public version.
raff808c852006-08-08 23:21:36 -0700186
187For maintainability, the list of names in each version block should
188be sorted in dictionary order (sort -d). Please comply.
Ali Bahramicd3e9332010-06-24 18:16:42 -0600190The version 2 mapfile language supports a simple mechanism for conditional
191input, in which lines in the mapfile apply only to a specific platform or
192ELFCLASS (32/64-bit). This mechanism works very much like the #if/#endif
193feature of the C preprocessor. For instance, the following mapfile declares
194a version SUNW_1.1 that always exports a symbol foo, and also exports
195the symbol bar on 32-bit sparc platforms:
Marcel Telka9557bef2014-04-27 10:57:35 +0200197$mapfile_version 2
Ali Bahramicd3e9332010-06-24 18:16:42 -0600198SYMBOL_VERSION SUNW_1.1 {
199 foo;
200$if _sparc && _ELF32
201 bar;
205Conditional input can be used if there are ISA-specific library interfaces
206not common to all instances of the library. It is the preferred method for
207expressing platform specific items, as long as the differences are simple
208(which is almost always the case). For example, see libproc, or, if you
Richard Lowe0409b952012-10-14 15:13:58 -0400209are masochistic, libc or libnsl. In general, use of this feature should be
Ali Bahramicd3e9332010-06-24 18:16:42 -0600211
212In addition to conditional input, there is a second heavier weight mechanism
213for expressing ISA-specific differences. In addition to the common mapfile:
raff808c852006-08-08 23:21:36 -0700214 common/mapfile-vers
Ali Bahramicd3e9332010-06-24 18:16:42 -0600215some libraries may have ISA-specific supplemental mapfiles, one in each
raff808c852006-08-08 23:21:36 -0700216of the ISA directories:
217 amd64/mapfile-vers
218 i386/mapfile-vers
219 sparc/mapfile-vers
220 sparcv9/mapfile-vers
raff808c852006-08-08 23:21:36 -0700221The ISA-specific mapfiles look like the common mapfile, except that only
222the ISA-specific names appear. The version names are the same as those
223in the common mapfile, but only non-empty version instances are present
Ali Bahramibfed4862009-02-10 09:38:02 -0700224and no inheritance specification is present. The link-editor reads the
225information from the common and ISA-specific mapfiles and merges them
226in memory into a single description used to create the resulting object.
raff808c852006-08-08 23:21:36 -0700227
Ali Bahramicd3e9332010-06-24 18:16:42 -0600228ISA-specific mapfiles were used with the version 1 mapfile language, which
229lacked conditional input. Their use is rare now, as conditional input is
230generally preferred. However, it is important to use conditional input
231carefully, or the resulting mapfile can be extremly difficult to read.
raff808c852006-08-08 23:21:36 -0700233-------------------------------------------------------------------------------
2354.0 Making interface additions to an existing library
2374.1 Adding a Public interface
Richard Lowe0409b952012-10-14 15:13:58 -0400239Public interfaces should be added to a new ILLUMOS_ symbol version, with the
240minor number incremented by one from the current highest version name. If
241this is the first Public interface in the shared object, a new ILLUMOS_0.1
242version name must be introduced.
raff808c852006-08-08 23:21:36 -0700243
244The major revision number is incremented whenever an incompatible change is
Richard Lowe0409b952012-10-14 15:13:58 -0400245made to an interface. This could be the case if an API changes so
246dramatically as to invalidate dependencies. This should almost never occur
247in practice. It also requires changing the suffix of the shared object
248from, say, .so.1 to .so.2 and introducing code to continue to ship the .so.1
249version of the library.
raff808c852006-08-08 23:21:36 -0700250
251The minor revision number is incremented whenever one or more new interfaces
Richard Lowe0409b952012-10-14 15:13:58 -0400252is added to a library. Once a version comes to exist in illumos, it is from
253that point onward considered to be immutable.
raff808c852006-08-08 23:21:36 -0700254
2554.2 Adding a Private interface
257Private interfaces are the non-ABI interfaces of the library. Unlike
258introducing a Public interface, a new entry is simply added to the
Richard Lowe0409b952012-10-14 15:13:58 -0400259private version. No minor number increment is necessary.
raff808c852006-08-08 23:21:36 -0700260
Richard Lowe0409b952012-10-14 15:13:58 -0400261If this interface happens to be the first Private interface introduced into
262the library, the private version must be created (with no major.minor
263version numbers). It inherits nothing, nothing inherits from it and it
264should be named ILLUMOSprivate.
raff808c852006-08-08 23:21:36 -0700265
Richard Lowe0409b952012-10-14 15:13:58 -0400266If the library already has Private interfaces in a SUNWprivate version, you
267should use that. They may have numbered version names like SUNWprivate_m.n
268(due to errors of the past). If so, just use the highest numbered private
269version name to version the new interface. There is no need to introduce a
270new private version name. Be careful not to use a lower numbered private
271version name; doing so can cause runtime errors (as opposed to load time
272errors) when running an application with older versions of the library.
raff808c852006-08-08 23:21:36 -0700273
Richard Lowe0409b952012-10-14 15:13:58 -0400274There are also libraries in illumos that contain only private interfaces. In
275such libraries, the private versions maybe legitimately be versioned and
276they may be incremented to ensure that the programs that depend on them are
277built and delivered as a integrated unit. A notable example of this is (usr/src/cmd/sgs/libld), which contains the implementation of the
279link-editor, the public interface to which is provided by the ld
280command. When making a modification to the interface of such a library, you
281should follow the convention already in place.
Ali Bahramibfed4862009-02-10 09:38:02 -0700282
Richard Lowe0409b952012-10-14 15:13:58 -04002834.3 Historical handling of Solaris update releases.
raff808c852006-08-08 23:21:36 -0700284
Richard Lowe0409b952012-10-14 15:13:58 -0400285To aid the understanding of our existing mapfiles, it is useful to note how
286interface versions were handled as they interacted with update releases of
287Solaris. Solaris update releases required careful coordination with the full
288release currently under development to keep symbol versions constant between
291Multiple update releases were generally shipped during the development of the
292next full release of Solaris. It was impossible to know in advance the full
293set of new interfaces in the next full release until it was complete. Some,
294though not all, new interfaces were included in the intervening update
295releases between full releases.
raff808c852006-08-08 23:21:36 -0700296
297Consequently, the new version number for an update cannot be a minor
Richard Lowe0409b952012-10-14 15:13:58 -0400298increment, but must be a micro increment to ensure that was a distinct
299version between the two releases. For example, if Release N had version
300number SUNW_1.3 and Release N+1 had SUNW_1.4, then interfaces added to
301an update of Release N must have micro numbers such as SUNW_1.3.1,
302SUNW_1.3.2, etc. (note that the micro number is not directly tied to the
303update number: SUNW_1.3.1 may have appeared in Update 2). The micro versions form
304an inheritance chain that is inserted between two successive minor versions.
305For example, the mapfile-vers file for minor release "N+1" to reflect its
306inclusion of micro releases will look like the following:
raff808c852006-08-08 23:21:36 -0700307
Ali Bahramicd3e9332010-06-24 18:16:42 -0600308$mapfile_version 2
310SYMBOL_VERSION SUNW_1.4 { # release N+1
raff808c852006-08-08 23:21:36 -0700311 global:
312 ...
313} SUNW_1.3.2;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600315SYMBOL_VERSION SUNW_1.3.2 { # micro release 2 (e.g., release NU3)
raff808c852006-08-08 23:21:36 -0700316 global:
317 ...
318} SUNW_1.3.1;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600320SYMBOL_VERSION SUNW_1.3.1 { # micro release 1 (e.g., release NU2)
raff808c852006-08-08 23:21:36 -0700321 global:
322 ...
323} SUNW_1.3;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600325SYMBOL_VERSION SUNW_1.3 { # release N
raff808c852006-08-08 23:21:36 -0700326 global:
327 ...
328} SUNW_1.2;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600330SYMBOL_VERSION SUNW_1.2 { # release N-1
raff808c852006-08-08 23:21:36 -0700331 global:
332 ...
333} SUNW_1.1;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600335SYMBOL_VERSION SUNW_1.1 { # first release
raff808c852006-08-08 23:21:36 -0700336 global:
337 ...
Ali Bahramicd3e9332010-06-24 18:16:42 -0600340SYMBOL_VERSION SUNW_private { # same in all releases
raff808c852006-08-08 23:21:36 -0700341 global:
342 ...
343 local:
344 *;
347The corresponding update/patch mapfile-vers file will be identical
348except for the exclusion of SUNW_1.4.
350Those interfaces which are only present in Release N+1 are always put
351into the next minor version set, SUNW_1.4.
Richard Lowe0409b952012-10-14 15:13:58 -0400353Thus when adding a new Public interface to an update release, both the mapfiles
354of the update release and next full release should have been modified to be
357There have been several cases of accidental deviation from this scheme, and
358existing mapfiles sometimes reflect this unfortunate state of affairs.
raff808c852006-08-08 23:21:36 -0700359
3625.0 How to update an interface in an existing library
3645.1 Removing an existing interface
3665.1.1 Moving a Public interface
Richard Lowe0409b952012-10-14 15:13:58 -0400368No Public interfaces should ever be removed from any mapfile, as this will
369break all existing consumers of that interface.
raff808c852006-08-08 23:21:36 -0700370
371To move an interface from one library to (say) libc, the code has to be
372deleted from the library and added to libc, then the mapfile for the
373library has to have the interface's entry changed from:
374 getfoobar;
Ali Bahramicd3e9332010-06-24 18:16:42 -0600376 getfoobar { TYPE = FUNCTION; FILTER = };
Richard Lowe0409b952012-10-14 15:13:58 -0400377This is an exception to the immutability of public symbol versions. See,
378for example, libnsl's common/mapfile-vers file.
raff808c852006-08-08 23:21:36 -0700379
380Follow the rules for adding a new interface for the necessary changes
Richard Lowe0409b952012-10-14 15:13:58 -0400381to libc's mapfile to accommodate the moved interface, including creating a
382new version in libc for the symbol.
raff808c852006-08-08 23:21:36 -0700383
Richard Lowe0409b952012-10-14 15:13:58 -0400384When merging an entire library into libc, the mapfile is changed to specify
385the type of each public symbol similarly to the above:
386 getfoobar;
388 getfoobar { TYPE = FUNCTION };
390But rather than specifying the library on which we filter for each symbol,
391the link-editor is invoked with '-F' to specify that our entire
392symbol table is a filter on libc. For examples, see libaio and librt.
raff808c852006-08-08 23:21:36 -0700393
3945.1.2 Removing a Private interface
396Deletion of Private interfaces is allowed, but caution should be taken;
397it should first be established that the interface is not being used.
398To remove a Private interface, simply delete the corresponding entry
Richard Lowe0409b952012-10-14 15:13:58 -0400399for that symbol from the mapfile's private version section.
raff808c852006-08-08 23:21:36 -0700400
401Do not forget to delete these Public or Private interfaces from the library's
402header files as well as from the code that implements the interfaces.
4045.2 Promoting a Private interface to Public
406This is similar to what's done when adding a Public interface. Promoting an
407existing Private interface to a Public one only requires a change to the
Richard Lowe0409b952012-10-14 15:13:58 -0400408existing interface definition. Private interfaces have the symbol version
409name "ILLUMOSprivate" or "SUNWprivate" associated with them. To make the
410interface a Public one, the interface must be added as if it were a new
411public symbol, following those same rules and removed from the private
raff808c852006-08-08 23:21:36 -0700413
Richard Lowe0409b952012-10-14 15:13:58 -0400414As an example, if we were modifying and its existing latest
415version were ILLUMOS_0.3, any new ABI would be put into a version called
416ILLUMOS_0.4. Therefore, whether you wish to promote an existing Private
417interface to Public, or to introduce a new Public interface, this (next
418successive minor numbered version level) would be the version that it would
419be associated with.
raff808c852006-08-08 23:21:36 -0700420
4215.3 Scoping a Private interface local
Ali Bahramibfed4862009-02-10 09:38:02 -0700423Any interfaces not present in the mapfile-vers file will be scoped local
424due to the presence of the
425 local:
426 *;
427lines discussed earlier. This ensures that such interfaces will not be visible
428outside the library. To move an interface from Private to local scope, simply
raff808c852006-08-08 23:21:36 -0700429remove the Private interface from the mapfile-vers file and the header file
430to prevent it from being exported. This may require moving the Private
431interface into a library-private header file. Scope reduction of Public
Richard Lowe0409b952012-10-14 15:13:58 -0400432interfaces is forbidden.
raff808c852006-08-08 23:21:36 -0700433
434For the interface to be used in more than one file within the library, it
435should be in a header file that can be included by each file in the library
436that uses the interface. For example:
438 #include "libprivate.h"
4405.4 How to copy interfaces which are part of a standard to a new or existing
441 library
443SYSVABI and SISCD are reserved version names for interfaces listed in the
444System V Interface Definition and the Sparc Compliance Definition. Avoid using
445these version names when copying the implementation of standard interfaces to
Richard Lowe0409b952012-10-14 15:13:58 -0400446another library. Instead, use ILLUMOS_0.1 for a new library, and ILLUMOS_m.n for
447an existing library (where m.n is the next version; i.e., if the
448last version was ILLUMOS_0.8, then you should version the interfaces with
raff808c852006-08-08 23:21:36 -0700450
4536.0 Introducing a new library
4556.1 Directories
Richard Lowe0409b952012-10-14 15:13:58 -0400457The normal discipline for introducing a new library in illumos is to create a
458new subdirectory of usr/src/lib. The interface definition discipline is to
raff808c852006-08-08 23:21:36 -0700459create a common/mapfile-vers file for the new library. If we were introducing
Richard Lowe0409b952012-10-14 15:13:58 -0400460a new foo library, libfoo, we'd create usr/src/lib/libfoo containing:
raff808c852006-08-08 23:21:36 -0700461 Makefile amd64/ i386/ sparcv9/
462 common/ sparc/
463The common subdirectory would contain the normal source files plus the
464mapfile-vers file. See usr/src/lib/README.Makefiles for directions on
465how to organize the Makefiles.
4676.2 The mapfile
469The new common/mapfile-vers file would contain:
Ali Bahramicd3e9332010-06-24 18:16:42 -0600471$mapfile_version 2
Richard Lowe0409b952012-10-14 15:13:58 -0400473SYMBOL_VERSION ILLUMOS_0.1 { # first release of libfoo
raff808c852006-08-08 23:21:36 -0700474 global:
475 ...
Richard Lowe0409b952012-10-14 15:13:58 -0400478SYMBOL_VERSION ILLUMOSprivate {
raff808c852006-08-08 23:21:36 -0700479 global:
480 ...
481 local:
482 *;
Richard Lowe0409b952012-10-14 15:13:58 -0400485If there are no Public interfaces, the ILLUMOS_0.1 section would be omitted.
486If there are no Private interfaces, the ILLUMOSprivate section would be
raff808c852006-08-08 23:21:36 -0700487omitted and the two lines:
488 local:
489 *;
Robert Mustacchi30a92f32015-10-22 07:58:43 -0700490would be moved into ILLUMOS_0.1.
raff808c852006-08-08 23:21:36 -0700491
Richard Lowe0409b952012-10-14 15:13:58 -0400492To decide which interfaces are Public (part of the ABI) and which are
493Private (unstable interfaces not intended to be used by third parties), the
494heuristic which works to a first approximation is that if it has a man page
495then it's Public.
raff808c852006-08-08 23:21:36 -0700496
497For maintainability, the list of names in each version block should
498be sorted in dictionary order (sort -d). Please comply.
5027.0 Make an entire library obsolete
5047.1 Introduce SUNWobsolete version
506Use this version name not for specific interfaces but for marking an entire
507library as obsolete. The existing public/private version names are left
508unchanged, but a new SUNWobsolete version is created with no symbols in it.
509This becomes a tag by which the obsolescence of the library can be recognized.
510There is no numbering of this version name.
Ali Bahramicd3e9332010-06-24 18:16:42 -0600512$mapfile_version 2
raff808c852006-08-08 23:21:36 -0700515 global:
516 SUNWobsolete; # This is the only way to do it.
517} SUNW_1.2;
Richard Lowe0409b952012-10-14 15:13:58 -0400519SYMBOL_VERSION ILLUMOS_0.2 {
raff808c852006-08-08 23:21:36 -0700520...
Richard Lowe0409b952012-10-14 15:13:58 -0400522You should continue to use the name SUNWobsolete even in illumos.
raff808c852006-08-08 23:21:36 -0700524-------------------------------------------------------------------------------
5268.0 Documentation
528For further information, please refer to the following documents:
Richard Lowe0409b952012-10-14 15:13:58 -0400530 "Solaris Linker and Libraries Guide"