The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

XNS (5)
  • >> XNS (5) ( Solaris man: Форматы файлов )
  •  

    NAME

    standards, ANSI, C, C++, ISO, POSIX, POSIX.1, POSIX.2, SUS, SUSv2, SUSv3, SVID, SVID3, XNS, XNS4, XNS5, XPG, XPG3, XPG4, XPG4v2 - standards and specifications supported by Solaris
     
    

    DESCRIPTION

    Solaris 10 supports IEEE Std 1003.1 and IEEE Std 1003.2, commonly known as POSIX.1 and POSIX.2, respectively. The following table lists each version of these standards with a brief description and the SunOS or Solaris release that first conformed to it.

    POSIX StandardDescriptionRelease

    POSIX.1-1988system interfaces and headersSunOS 4.1

    POSIX.1-1990

    POSIX.1b-1993

    POSIX.1c-1996

    POSIX.2-1992

    POSIX.2a-1992

    POSIX.1-2001

    Solaris 10 also supports the X/Open Common Applications Environment (CAE) Portability Guide Issue 3 (XPG3) and Issue 4 (XPG4); Single UNIX Specification (SUS, also known as XPG4v2); Single UNIX Specification, Version 2 (SUSv2); and Single UNIX Specification, Version 3 (SUSv3). Both XPG4 and SUS include Networking Services Issue 4 (XNS4). SUSv2 includes Networking Services Issue 5 (XNS5).

    The following table lists each X/Open specification with a brief description and the SunOS or Solaris release that first conformed to it.

    X/Open CAE


     Specification
    DescriptionRelease

    XPG3

    XPG4

    SUS (XPG4v2)

    XNS4

    SUSv2

    XNS5

    SUSv3

    The XNS4 specification is safe for use only in ILP32 (32-bit) environments and should not be used for LP64 (64-bit) application environments. Use XNS5 or SUSv3, which have LP64-clean interfaces that are portable across ILP32 and LP64 environments. Solaris releases 7 through 10 support both the ILP32 and LP64 environments.

    Solaris releases 7 through 10 have been branded to conform to The Open Group's UNIX 98 Product Standard. Solaris 10 has been branded to conform to The Open Group's UNIX 03 Product Standard.

    Solaris releases 2.0 through 10 support the interfaces specified by the System V Interface Definition, Third Edition, Volumes 1 through 4 (SVID3). Note, however, that since the developers of this specification (UNIX Systems Laboratories) are no longer in business and since this specification defers to POSIX and X/Open CAE specifications, there is some disagreement about what is currently required for conformance to this specification.

    When Sun Studio C Compiler 5.6 is installed, Solaris releases 2.0 through 10 support the ANSI X3.159-1989 Programming Language - C and ISO/IEC 9899:1990 Programming Language - C (C) interfaces.

    When Sun Studio C Compiler 5.6 is installed, Solaris releases 7 through 10 support ISO/IEC 9899:1990 Amendment 1:1995: C Integrity.

    When Sun Studio C Compiler 5.6 is installed, Solaris 10 supports ISO/IEC 9899:1999 Programming Languages - C.

    When Sun Studio C++ Compiler 5.6 is installed, Solaris releases 2.5.1 through 10 support ISO/IEC 14882:1998 Programming Languages - C++. Unsupported features of that standard are described in the compiler README file.  

    Utilities

    If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 conflicts with historical Solaris utility behavior, the original Solaris version of the utility is unchanged; a new version that is standard-conforming has been provided in /usr/xpg4/bin. If the behavior required by POSIX.1-2001 or SUSv3 conflicts with historical Solaris utility behavior, a new version that is standard-conforming has been provided in /usr/xpg4/bin or in /usr/xpg6/bin. If the behavior required by POSIX.1-2001 or SUSv3 conflicts with POSIX.2, POSIX.2a, SUS, or SUSv2, a new version that is SUSv3 standard-conforming has been provided in /usr/xpg6/bin.

    An application that wants to use standard-conforming utilitues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) environment variable to specify the directories listed below in the order specified to get the appropriate utilities:

    SVID3, XPG3

    1.
    /usr/ccs/bin
    2.
    /usr/bin
    3.
    directory containing binaries for your compiler
    4.
    other directories containing binaries needed by the application

    POSIX.2, POSIX.2a, SUS, SUSv2, XPG4

    1.
    /usr/xpg4/bin
    2.
    /usr/ccs/bin
    3.
    /usr/bin
    4.
    directory containing binaries for your compiler
    5.
    other directories containing binaries needed by the application

    POSIX.1-2001, SUSv3

    1.
    /usr/xpg6/bin
    2.
    /usr/xpg4/bin
    3.
    /usr/ccs/bin
    4.
    /usr/bin
    5.
    directory containing binaries for your compiler
    6.
    other directories containing binaries needed by the application

    When an application uses execlp() or execvp() (see exec(2)) to execute a shell file, or uses system(3C), the shell used to interpret the shell file depends on the standard to which the caller conforms:

    StandardShell Used

    1989 ANSI C, 1990 ISO C, 1999 ISO C, POSIX.1 (1990-2001), SUS, SUSv2, SUSv3, XPG4 /usr/xpg4/bin/sh
    POSIX.1 (1988), SVID3, XPG3, no standard specified

     

    Feature Test Macros

    Feature test macros are used by applications to indicate additional sets of features that are desired beyond those specified by the C standard. If an application uses only those interfaces and headers defined by a particular standard (such as POSIX or X/Open CAE), then it need only define the appropriate feature test macro specified by that standard. If the application is using interfaces and headers not defined by that standard, then in addition to defining the appropriate standard feature test macro, it must also define __EXTENSIONS__. Defining __EXTENSIONS__ provides the application with access to all interfaces and headers not in conflict with the specified standard. The application must define __EXTENSIONS__ either on the compile command line or within the application source files.  

    1989 ANSI C, 1990 ISO C, 1999 ISO C

    No feature test macros need to be defined to indicate that an application is a conforming C application.  

    ANSI/ISO C++

    ANSI/ISO C++ does not define any feature test macros. If the standard C++ announcement macro __cplusplus is predefined to value 199711 or greater, the compiler operates in a standard-conforming mode, indicating C++ standards conformance. The value 199711 indicates conformance to ISO/IEC 14882:1998, as required by that standard. (As noted above, conformance to the standard is incomplete.) A standard-conforming mode is not available with compilers prior to Sun WorkShop C++ 5.0.

    C++ bindings are not defined for POSIX or X/Open CAE, so specifying feature test macros such as _POSIX_SOURCE, _POSIX_C_SOURCE, and _XOPEN_SOURCE can result in compilation errors due to conflicting requirements of standard C++ and those specifications.  

    POSIX

    Applications that are intended to be conforming POSIX.1 applications must define the feature test macros specified by the standard before including any headers. For the standards listed below, applications must define the feature test macros listed. Application writers must check the corresponding standards for other macros that can be queried to determine if desired options are supported by the implementation.

    POSIX StandardFeature Test Macros

    POSIX.1-1990_POSIX_SOURCE

    POSIX.1-1990 and POSIX.2-1992 C-Language Bindings Option
    POSIX.1b-1993

    POSIX.1c-1996

    POSIX.1-2001

     

    SVID3

    The SVID3 specification does not specify any feature test macros to indicate that an application is written to meet SVID3 requirements. The SVID3 specification was written before the C standard was completed.  

    X/Open CAE

    To build or compile an application that conforms to one of the X/Open CAE specifications, use the following guidelines. Applications need not set the POSIX feature test macros if they require both CAE and POSIX functionality.

    XPG3

    The application must define _XOPEN_SOURCE. If _XOPEN_SOURCE is defined with a value, the value must be less than 500.

    XPG4

    The application must define _XOPEN_SOURCE and set _XOPEN_VERSION=4. If _XOPEN_SOURCE is defined with a value, the value must be less than 500.

    SUS (XPG4v2)

    The application must define _XOPEN_SOURCE and set _XOPEN_SOURCE_EXTENDED=1. If _XOPEN_SOURCE is defined with a value, the value must be less than 500.

    SUSv2

    The application must define _XOPEN_SOURCE=500.

    SUSv3

    The application must define _XOPEN_SOURCE=600.

     

    Compilation

    A POSIX.1 (1988-1996)-, XPG4-, SUS-, or SUSv2-conforming implementation must include an ANSI X3.159-1989 (ANSI C Language) standard-conforming compilation system and the cc and c89 utilities. A POSIX.1-2001- or SUSv3-conforming implementation must include an ISO/IEC 99899:1999 (1999 ISO C Language) standard-conforming compilation system and the c99 utility. Solaris 10 was tested with the cc, c89, and c99 utilities and the compilation environment provided by Sun Studio C Compiler 5.6.

    When cc is used to link applications, /usr/lib/values-xpg4.o must be specified on any link/load command line, unless the application is POSIX.1-2001- or SUSv3-conforming, in which case /usr/lib/values-xpg6.o must be specified on any link/load compile line. The preferred way to build applications, however, is described in the table below.

    An XNS4- or XNS5-conforming application must include -l XNS on any link/load command line in addition to defining the feature test macros specified for SUS or SUSv2, respectively.

    If the compiler suppports the redefine_extname pragma feature (the Sun Studio C Compiler 5.6 compilers define the macro __PRAGMA_REDEFINE_EXTNAME to indicate that it supports this feature), then the standard headers use #pragma redefine_extname directives to properly map function names onto library entry point names. This mapping provides full support for ISO C, POSIX, and X/Open namespace reservations.

    If this pragma feature is not supported by the compiler, the headers use the #define directive to map internal function names onto appropriate library entry point names. In this instance, applications should avoid using the explicit 64-bit file offset symbols listed on the lf64(5) manual page, since these names are used by the implementation to name the alternative entry points.

    When using Sun Studio C Compiler 5.6 compilers, applications conforming to the specifications listed above should be compiled using the utilities and flags indicated in the following table:

    Specification            Compiler/Flags         Feature Test Macros
    _________________________________________________________________________
    1989 ANSI C and 1990 ISO C    c89                none
    _________________________________________________________________________
    1999 ISO C                    c99                none
    _________________________________________________________________________
    SVID3                         cc -Xt -xc99=none  none
    _________________________________________________________________________
    POSIX.1-1990                  c89                _POSIX_SOURCE
    _________________________________________________________________________
    POSIX.1-1990 and POSIX.2-1992 c89                _POSIX_SOURCE  and
     C-Language Bindings Option                     POSIX_C_SOURCE=2
    _________________________________________________________________________
    POSIX.1b-1993                 c89                _POSIX_C_SOURCE=199309L
    _________________________________________________________________________
    POSIX.1c-1996                 c89                _POSIX_C_SOURCE=199506L
    _________________________________________________________________________
    POSIX.1-2001                  c99                _POSIX_C_SOURCE=200112L
    _________________________________________________________________________
    POSIX.1c-1996                 c89                _POSIX_C_SOURCE=199506L
    _________________________________________________________________________
    CAE XPG3                      cc -Xa -xc99=none  _XOPEN_SOURCE
    _________________________________________________________________________
    CAE XPG4                      c89                _XOPEN_SOURCE and
                                                    _XOPEN_VERSION=4
    _________________________________________________________________________
    SUS (CAE XPG4v2)              c89                _XOPEN_SOURCE and
     (includes XNS4)                                 _XOPEN_SOURCE_EXTENDED=1
    _________________________________________________________________________
    SUSv2 (includes XNS5)         c89                _XOPEN_SOURCE=500
    _________________________________________________________________________
    SUSv3                         c99                _XOPEN_SOURCE=600
    

    For platforms supporting the LP64 (64-bit) programming environment, SUSv2-conforming LP64 applications using XNS5 library calls should be built with command lines of the form:

    c89 $(getconf XBS5_LP64_OFF64_CFLAGS) -D_XOPEN_SOURCE=500 \
       $(getconf XBS5_LP64_OFF64_LDFLAGS) foo.c -o foo \
       $(getconf XBS5_LP64_OFF64_LIBS) -lxnet
    

    Similar SUSv3-conforming LP64 applications should be built with command lines of the form:

    c99 $(getconf POSIX_V6_LP64_OFF64_CFLAGS) -D_XOPEN_SOURCE=600 \
       $(getconf POSIX_V6_LP64_OFF64_LDFLAGS) foo.c -o foo \
       $(getconf POSIX_V6_LP64_OFF64_LIBS) -lxnet
    

     

    SUSv3

    c99

    _XOPEN_SOURCE=600

     

    SEE ALSO

    csh(1), ksh(1), sh(1), exec(2), sysconf(3C), system(3C), environ(5), lf64(5)


     

    Index

    NAME
    DESCRIPTION
    Utilities
    Feature Test Macros
    1989 ANSI C, 1990 ISO C, 1999 ISO C
    ANSI/ISO C++
    POSIX
    SVID3
    X/Open CAE
    Compilation
    SUSv3
    SEE ALSO


    Поиск по тексту MAN-ов: 




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру