IRIX Base Documentation 2001 May/SGI IRIX Base Documentation 2001 May.iso/usr/share/catman/p_man/cat3/libdl/dlopen.z/dlopen

Text File | 1998-10-30 | 28.7 KB | 397 lines

DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))                                                          DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))



NNNNAAAAMMMMEEEE
     ddddllllooooppppeeeennnn - open a shared object

SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
     cccccccc [ffffllllaaaagggg ...] ffffiiiilllleeee ...  ----llllcccc [lllliiiibbbbrrrraaaarrrryyyy ...]

     ####iiiinnnncccclllluuuuddddeeee <<<<ddddllllffffccccnnnn....hhhh>>>>

     vvvvooooiiiidddd ****ddddllllooooppppeeeennnn((((ccccoooonnnnsssstttt cccchhhhaaaarrrr ****ppppaaaatttthhhhnnnnaaaammmmeeee,,,, iiiinnnntttt mmmmooooddddeeee))));;;;

DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
     ddddllllooooppppeeeennnn is one of a family of routines that give the user direct access to
     the dynamic linking facilities. These routines are available in a library
     which is loaded if the option ----llllcccc is used with cccccccc , ffff77777777 or lllldddd.

     ddddllllooooppppeeeennnn makes a shared object available to a running process.  ddddllllooooppppeeeennnn
     returns to the process a _h_a_n_d_l_e which the process may use on subsequent
     calls to ddddllllssssyyyymmmm and ddddllllcccclllloooosssseeee.  This _h_a_n_d_l_e should not be interpreted in any
     way by the process.  _p_a_t_h_n_a_m_e is the path name of the object to be
     opened; it may be an absolute path or relative to the current directory.
     If the value of _p_a_t_h_n_a_m_e is 0, ddddllllooooppppeeeennnn makes the symbols contained in the
     original aaaa....oooouuuutttt, and all of the objects that were loaded at program
     startup with the aaaa....oooouuuutttt, available through ddddllllssssyyyymmmm.

     When a shared object is brought into the address space of a process, it
     may contain references to symbols whose addresses are not known until the
     object is loaded.  These references must be relocated before the symbols
     can be accessed. The _m_o_d_e parameter governs when these relocations take
     place and may have the following values:

     RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY
          Only references to data symbols are relocated when the object is
          loaded.  References to functions are not relocated until a given
          function is invoked for the first time.  This _m_o_d_e should result in
          the best performance, since a process may not reference all of the
          functions in any given shared object.  RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY cannot be combined
          with RRRRTTTTLLLLDDDD____NNNNOOOOWWWW.

     RRRRTTTTLLLLDDDD____NNNNOOOOWWWW
          All necessary relocations are performed when the object is first
          loaded.  This may result in some wasted effort if relocations are
          performed for functions that are never referenced, but is useful for
          programs that need to know as soon as an object is loaded that all
          symbols referenced during execution are available.  RRRRTTTTLLLLDDDD____NNNNOOOOWWWW cannot
          be combined with RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY.

     RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL
          modifies the treatment of the symbols in the DSO being opened to be
          identical to those of ssssggggiiii____ddddllllaaaadddddddd().  RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL may be or'd with
          either RRRRTTTTLLLLDDDD____NNNNOOOOWWWW or RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY (RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL cannot be the mmmmooooddddeeee value
          on its own).  RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL See "NAMESPACE ISSUES" below for more on
          the impact of using or not using RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL.  With RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL the



                                                                        PPPPaaaaggggeeee 1111






DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))                                                          DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))



          _h_a_n_d_l_e is less necessary than without it, since _r_l_d directly
          resolves references to symbols when RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL is provided and
          _d_l_s_y_m is not needed.

     The following is an example of use, using -32.
          _dddd_llll_tttt_rrrr_yyyy_...._cccc_::::
          _----_----_----_----_----_----_----
          _////_**** _EEEE_rrrr_rrrr_oooo_rrrr _hhhh_aaaa_nnnn_dddd_llll_iiii_nnnn_gggg _cccc_oooo_dddd_eeee _nnnn_oooo_tttt _ssss_hhhh_oooo_wwww_nnnn_....
          _****_////
          _####_iiii_nnnn_cccc_llll_uuuu_dddd_eeee _<<<<_dddd_llll_ffff_cccc_nnnn_...._hhhh_>>>>

          _tttt_yyyy_pppp_eeee_dddd_eeee_ffff _iiii_nnnn_tttt _((((_****_xxxx_aaaa_mmmm_pppp_llll_eeee_ffff_uuuu_nnnn_cccc_pppp_tttt_rrrr_))))_((((_iiii_nnnn_tttt_))))_;;;;
          _iiii_nnnn_tttt _mmmm_aaaa_iiii_nnnn_((((_))))
          _{{{{
             _vvvv_oooo_iiii_dddd _****_hhhh_aaaa_nnnn_dddd_llll_eeee_;;;;
             _iiii_nnnn_tttt   _iiii_;;;;
             _xxxx_aaaa_mmmm_pppp_llll_eeee_ffff_uuuu_nnnn_cccc_pppp_tttt_rrrr _ffff_pppp_tttt_rrrr_;;;;

             _hhhh_aaaa_nnnn_dddd_llll_eeee _==== _dddd_llll_oooo_pppp_eeee_nnnn_((((_""""_gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_...._ssss_oooo_""""_,,,, _RRRR_TTTT_LLLL_DDDD______LLLL_AAAA_ZZZZ_YYYY_))))_;;;;
             _ffff_pppp_tttt_rrrr _==== _((((_xxxx_aaaa_mmmm_pppp_llll_eeee_ffff_uuuu_nnnn_cccc_pppp_tttt_rrrr_))))_dddd_llll_ssss_yyyy_mmmm_((((_hhhh_aaaa_nnnn_dddd_llll_eeee_,,,, _""""_gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_""""_))))_;;;;
             _iiii _==== _((((_****_ffff_pppp_tttt_rrrr_))))_((((_3333_))))_;;;;
             _rrrr_eeee_tttt_uuuu_rrrr_nnnn _0000_;;;;
          _}}}}

          _gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_...._cccc_::::
          _----_----_----_----_----_----_----_----_----_----_----
          _####_iiii_nnnn_cccc_llll_uuuu_dddd_eeee _<<<<_ssss_tttt_dddd_iiii_oooo_...._hhhh_>>>>
          _iiii_nnnn_tttt _gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_((((_iiii_nnnn_tttt _nnnn_uuuu_mmmm______gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_))))
          _{{{{
             _iiii_nnnn_tttt _iiii_;;;;

             _ffff_oooo_rrrr _((((_iiii_====_0000_;;;; _iiii _<<<< _nnnn_uuuu_mmmm______gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_;;;; _iiii_++++_++++_))))
                _pppp_rrrr_iiii_nnnn_tttt_ffff _((((_""""_hhhh_eeee_llll_llll_oooo _wwww_oooo_rrrr_llll_dddd_0000_))))_;;;;
             _rrrr_eeee_tttt_uuuu_rrrr_nnnn _1111_;;;;
          _}}}}


          _%%%% _cccc_cccc _----_3333_2222 _----_cccc _dddd_llll_tttt_rrrr_yyyy_...._cccc _gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_...._cccc
          _%%%% _llll_dddd _----_3333_2222 _----_ssss_hhhh_aaaa_rrrr_eeee_dddd _gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_...._oooo _\\\\
          _----_ssss_oooo_nnnn_aaaa_mmmm_eeee _gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_...._ssss_oooo _----_oooo _gggg_rrrr_eeee_eeee_tttt_iiii_nnnn_gggg_ssss_...._ssss_oooo
          _%%%% _cccc_cccc _----_3333_2222 _dddd_llll_tttt_rrrr_yyyy_...._oooo
          _%%%% _aaaa_...._oooo_uuuu_tttt
          _hhhh_eeee_llll_llll_oooo _wwww_oooo_rrrr_llll_dddd
          _hhhh_eeee_llll_llll_oooo _wwww_oooo_rrrr_llll_dddd
          _hhhh_eeee_llll_llll_oooo _wwww_oooo_rrrr_llll_dddd

NNNNAAAAMMMMEEEESSSSPPPPAAAACCCCEEEE IIIISSSSSSSSUUUUEEEESSSS
     This section does not address symbol resolution from ddddllllssssyyyymmmm(3).  See ddddllllssssyyyymmmm
     for details on its symbol resolution rules.






                                                                        PPPPaaaaggggeeee 2222






DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))                                                          DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))



     Name resolution can become surprisingly complicated and non-intuitive in
     the presence of programs or DSOs using ddddllllooooppppeeeennnn, ssssggggiiiiddddllllaaaadddddddd,
     ssssggggiiii____ddddllllooooppppeeeennnn____vvvveeeerrrrssssiiiioooonnnn, or LLLLLLLL____DDDDEEEELLLLAAAAYYYY____LLLLOOOOAAAADDDD (the _l_d -_d_e_l_a_y__l_o_a_d option).

     Any case in which there is only one definition of a symbol across all
     loaded DSOs is simple: that definition is used if it is visible
     (visibility is discussed below).

     Name searches are done in the order of a single list, the rld-list.  The
     first rld-list entry is the program itself.  Following that is the list
     of DSOs currently in the runtime of the program.  At program startup a
     breadth-first list of DSOs in the program (and, recursively their library
     lists) is formed in the rld-list.  No DSO is added to the rld-list twice
     (later encounters of a DSO in simply use the earlier occurrence, but see
     NOTES below for an exception).  For any DSO library list entry marked
     LLLLLLLL____DDDDEEEELLLLAAAAYYYY____LLLLOOOOAAAADDDD the DSO referenced is not loaded at program startup.

     The above name search rule has an exception.  If a DSO is marked as
     DT_SYMBOLIC (see the _l_d option ----BBBB ssssyyyymmmmbbbboooolllliiiicccc) then all name searches from
     within that DSO begin at the DSO itself and continue with the standard
     rld-list search.

     When, as a result of a call to  a function in a LLLLLLLL____DDDDEEEELLLLAAAAYYYY____LLLLOOOOAAAADDDDed DSO, that
     DSO is loaded, the new DSO is added at the end of the rld-list (if it has
     any entries in its library list that are not marked LLLLLLLL____DDDDEEEELLLLAAAAYYYY____LLLLOOOOAAAADDDD the
     non-LLLLLLLL____DDDDEEEELLLLAAAAYYYY____LLLLOOOOAAAADDDD DSOs are added, recursively (breadth-first)).  Thus,
     depending on the order of calls to delay-loaded DSOs, the order of DSOs
     on the rld-list may be different from one run of a program to the next.

     The order of DSOs in the rld-list may not match the order in any given
     library list because if a DSO is already in the rld-list it is not added
     a second time to the rld-list.

     As a result of the rule that the search order is rld-list order, the
     symbol found can be surprising.  Consider a symbol A found in DSOs B and
     C and DSO B is before DSO C in E's liblist while DSO B is after DSO C in
     F's liblist.  Lets specify that neither DSO B nor DSO C are otherwise
     referenced.  If DSO E is ddddllllooooppppeeeennnn((((............RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL))))ed before DSO F then the A
     from DSO B is found by ddddllllssssyyyymmmm from either handle.  While if DSO F is
     ddddllllooooppppeeeennnn((((............RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL))))ed before DSO E then the A from DSO C is found by
     ddddllllssssyyyymmmm from either handle.  On the other hand, if only one of the DSOs E
     or F is ddddllllooooppppeeeennnn((((............RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL))))ed then one gets DSO B's A from DSO E's
     handle and one gets DSO C's A from DSO F's handle.

     Note that _d_l_c_l_o_s_e does not cause any reordering of the rld-list: when the
     last handle (direct or indirect) on a DSO is _d_l_c_l_o_s_ed the DSO is removed
     from the rld-list.  Before the final _d_l_c_l_o_s_e the DSO remains where it was
     on the rld-list.

     Now we turn to the issue of symbol visibility.





                                                                        PPPPaaaaggggeeee 3333






DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))                                                          DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))



     DSOs loaded by a single invocation of ddddllllooooppppeeeennnn may import symbols from one
     another or from any DSO which is globally-visible, but DSOs loaded by one
     ddddllllooooppppeeeennnn invocation may not directly reference symbols from DSOs loaded by
     a different ddddllllooooppppeeeennnn invocation. Those symbols may, however, be referenced
     indirectly using ddddllllssssyyyymmmm.

     Globally-visible DSOs are those added at program startup or via delay-
     load from a globally-visible object.  In addition, any DSO added by
     ssssggggiiiiddddllllaaaadddddddd or ddddllllooooppppeeeennnn((((............RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL............)))) or
     ssssggggiiiiddddllllooooppppeeeennnn____vvvveeeerrrrssssiiiioooonnnn((((............RRRRTTTTLLLLDDDD____GGGGLLLLOOOOBBBBAAAALLLL............)))) is globally-visible.

     Even in a globally-visible DSO a symbol is invisible to any access from
     outside the DSO if the symbol is marked SSSSTTTTOOOO____HHHHIIIIDDDDDDDDEEEENNNN (see the _l_d options
     ----hhhhiiiiddddddddeeeennnn____ssssyyyymmmmbbbboooollll or ----hhhhiiiiddddeeeessss____ffffiiiilllleeee for example).  From within a DSO, all
     symbols in that DSO are visible.  From within a DSO, all globally-visible
     symbols are visible.

     Consider a set of DSOs.

     ld -shared -all F.a -o F.so
     ld -shared -all G.a -o G.so
     ld -shared -all E.a F.so G.so -o E.so
     ld -shared -all H.a F.so  -o H.so

     Say a program does dlopen("E.so",RTLD_LAZY) and and
     dlopen("H.so",RTLD_LAZY) and uses _d_l_s_y_m to find functions through the two
     _h_a_n_d_l_es and calls these two functions. Say each of these calls a function
     that calls ff() in F.so. Say that ff() calls fg() which is only defined
     in G.so. Logically one would say that the call through the function
     accessed via E.so should resolve to fg() in G.so and one would think that
     the call thru the function accessed via H.so should result in an
     undefined function.  However, _r_l_d does not attempt to determine (by
     walking the run-time stack or other means) the exact call-stack to ff()
     (the call-stack is not really enough: _r_l_d needs to know the _h_a_n_d_l_e used
     to derive the calls!).  The result of the call to fg() is undefined.
     What happens is that fg() in G.so is called, since such would be legal if
     the call path were thru E.so's _h_a_n_d_l_e.  It is unwise to depend on such
     behavior.

SSSSEEEEAAAARRRRCCCCHHHHIIIINNNNGGGG FFFFOOOORRRR SSSSHHHHAAAARRRREEEEDDDD OOOOBBBBJJJJEEEECCCCTTTTSSSS
     If other shared objects were link edited with _p_a_t_h_n_a_m_e when _p_a_t_h_n_a_m_e was
     built, those objects are automatically loaded by ddddllllooooppppeeeennnn (subject to the
     LLLLLLLL____DDDDEEEELLLLAAAAYYYY____LLLLOOOOAAAADDDD library list flag).  The directory search path that is used
     to find both _p_a_t_h_n_a_m_e and the other _n_e_e_d_e_d objects is the same as that
     used by rrrrlllldddd(1).  In particular, _p_a_t_h_n_a_m_e is searched for in

     1) the directory specified by _p_a_t_h_n_a_m_e if it is not a simple file name
     (_i._e.  it contains a //// character).  In this case, the exact file is the
     only placed searched; steps two through four below are ignored.

     2) any path specified via the ----rrrrppppaaaatttthhhh argument to lllldddd(1) when the
     executable was statically linked.



                                                                        PPPPaaaaggggeeee 4444






DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))                                                          DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))



     3) any directory specified by the environment variable LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH.
     This environment variable should contain a colon-separated list of
     directories, in the same format as the PPPPAAAATTTTHHHH variable [see sssshhhh(1)].  64-bit
     programs examine the variable LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY66664444____PPPPAAAATTTTHHHH, and if it is not set
     LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH is examined.  New 32-bit ABI programs examine the
     variable LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYYNNNN33332222____PPPPAAAATTTTHHHH and if it is not set LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH is
     examined.

     All of these variables are ignored if the process is running sssseeeettttuuuuiiiidddd or
     sssseeeettttggggiiiidddd [see eeeexxxxeeeecccc(2)].

     4) the default search paths are used.  These are ////uuuussssrrrr////lllliiiibbbb::::////lllliiiibbbb for 32-bit
     programs, ////uuuussssrrrr////lllliiiibbbb66664444::::////lllliiiibbbb66664444 for 64-bit programs, and ////uuuussssrrrr////lllliiiibbbb33332222::::////lllliiiibbbb33332222
     for new 32-bit ABI programs.

     The variable ____RRRRLLLLDDDD____RRRROOOOOOOOTTTT has its usual effect, as documented on rrrrlllldddd(1)
     (which means that if the process is running sssseeeettttuuuuiiiidddd or sssseeeettttggggiiiidddd ____RRRRLLLLDDDD____RRRROOOOOOOOTTTT is
     ignored).

SSSSEEEEEEEE AAAALLLLSSSSOOOO
     ddddlllleeeerrrrrrrroooorrrr(3), ddddllllcccclllloooosssseeee(3), ssssggggiiiiddddllllaaaadddddddd(3), ssssggggiiiiddddllllooooppppeeeennnn____vvvveeeerrrrssssiiiioooonnnn(3), ddddllllssssyyyymmmm(3),
     ddddssssoooo(5).

DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS
     If _p_a_t_h_n_a_m_e cannot be found, cannot be opened for reading, is not a
     shared object, or if an error occurs during the process of loading
     _p_a_t_h_n_a_m_e or relocating its symbolic references, ddddllllooooppppeeeennnn returns NNNNUUUULLLLLLLL.
     More detailed diagnostic information is available through ddddlllleeeerrrrrrrroooorrrr.

NNNNOOOOTTTTEEEESSSS
     Objects whose names resolve to the same absolute or relative path name
     may be opened any number of times using ddddllllooooppppeeeennnn, however, the object
     referenced is only loaded once into the address space of the current
     process.  The same object referenced by two different path names,
     however, may be loaded multiple times.  For example, given the object
     ////uuuussssrrrr////hhhhoooommmmeeee////mmmmeeee////mmmmyyyylllliiiibbbbssss////mmmmyyyylllliiiibbbb....ssssoooo, and assuming the current working directory
     is ////uuuussssrrrr////hhhhoooommmmeeee////mmmmeeee////wwwwoooorrrrkkkkddddiiiirrrr,

          ............
          vvvvooooiiiidddd ****hhhhaaaannnnddddlllleeee1111;;;;
          vvvvooooiiiidddd ****hhhhaaaannnnddddlllleeee2222;;;;

          hhhhaaaannnnddddlllleeee1111 ==== ddddllllooooppppeeeennnn((((""""........////mmmmyyyylllliiiibbbbssss////mmmmyyyylllliiiibbbb....ssssoooo"""",,,, RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY))));;;;
          hhhhaaaannnnddddlllleeee2222 ==== ddddllllooooppppeeeennnn((((""""////uuuussssrrrr////hhhhoooommmmeeee////mmmmeeee////mmmmyyyylllliiiibbbbssss////mmmmyyyylllliiiibbbb....ssssoooo"""",,,, RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY))));;;;
          ............

     results in mmmmyyyylllliiiibbbbssss....ssssoooo being loaded twice for the current process.  On the
     other hand, given the same object and current working directory, if
     LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH====////uuuussssrrrr////hhhhoooommmmeeee////mmmmeeee////mmmmyyyylllliiiibbbbssss, then






                                                                        PPPPaaaaggggeeee 5555






DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))                                                          DDDDLLLLOOOOPPPPEEEENNNN((((3333CCCC))))



          ............
          vvvvooooiiiidddd ****hhhhaaaannnnddddlllleeee1111;;;;
          vvvvooooiiiidddd ****hhhhaaaannnnddddlllleeee2222;;;;

          hhhhaaaannnnddddlllleeee1111 ==== ddddllllooooppppeeeennnn((((""""mmmmyyyylllliiiibbbb....ssssoooo"""",,,, RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY))));;;;
          hhhhaaaannnnddddlllleeee2222 ==== ddddllllooooppppeeeennnn((((""""////uuuussssrrrr////hhhhoooommmmeeee////mmmmeeee////mmmmyyyylllliiiibbbbssss////mmmmyyyylllliiiibbbb....ssssoooo"""",,,, RRRRTTTTLLLLDDDD____LLLLAAAAZZZZYYYY))));;;;
          ............

     results in mmmmyyyylllliiiibbbbssss....ssssoooo being loaded only once. Users who wish to gain
     access to the symbol table of the aaaa....oooouuuutttt itself using ddddllllssssyyyymmmm((((0000,,,, mmmmooooddddeeee))))
     should be aware that some symbols defined in the aaaa....oooouuuutttt may not be
     available to the dynamic linker.  The symbol table created by lllldddd for use
     by the dynamic linker might contain only a subset of the symbols defined
     in the aaaa....oooouuuutttt:  specifically those referenced by the shared objects with
     which the aaaa....oooouuuutttt is linked.

     A program built non_shared (with cc -non_shared for example) cannot
     usefully call _d_l_o_p_e_n(), _d_l_s_y_m(), _d_l_e_r_r_o_r(), _s_g_i_d_l_o_p_e_n__v_e_r_s_i_o_n(),
     _s_g_i_d_l_a_d_d(), or _d_l_c_l_o_s_e() since there is no defined mechanism for dynamic
     loading in non_shared programs.  The dynamic loading routines are not
     included in the non_shared _l_i_b_c._a so attempting to use them may result in
     a failure at link time.  Any program built non_shared that wishes to
     retain code calling the dynamic loading routines must implement its own
     versions of _d_l_o_p_e_n, _d_l_s_y_m(3), etc. and simply return appropriate error
     values to avoid the link-time errors.  (Building programs non_shared is
     not generally recommended.  Not all libraries are available non_shared.)

     Use of ddddllllcccclllloooosssseeee on a DSO can cause surprising side effects because ddddllllcccclllloooosssseeee
     forces many symbol GOT entries to be reset for re-lazy-evaluation.  A
     result of this is that previously-saved (by the application or some
     library) function pointers may hold values that could be obsolete or no
     longer correct.  This is a problem for any ddddllllcccclllloooosssseeee but is more serious
     (can cause more surprises) when ddddllllcccclllloooosssseeeeing a _h_a_n_d_l_e on a globally-visible
     DSO.

     Symbol lookups proceed in order on a linear list, and a DSO is not opened
     twice with the same version number  (unless different dlopen paths make
     the DSO name appear different to _r_l_d).  When multiple ssssggggiiiiddddllllaaaadddddddds are done
     and an earlier DSO is ddddllllcccclllloooosssseeeed this can change what symbol a call is
     resolved to.  See "NAMESPACE ISSUES" above.















                                                                        PPPPaaaaggggeeee 6666