问dlmopen和dlopen的用例是什么？

EN

   The  dlmopen()  function differs from dlopen() primarily in that it ac‐
   cepts an additional argument, lmid, that specifies  the  link-map  list
   (also  referred to as a namespace) in which the shared object should be
   loaded.  (By comparison, dlopen() adds the  dynamically  loaded  shared
   object  to  the  same  namespace  as  the  shared object from which the
   dlopen() call is made.)  The Lmid_t  type  is  an  opaque  handle  that
   refers to a namespace.

   The  lmid argument is either the ID of an existing namespace (which can
   be obtained using the dlinfo(3) RTLD_DI_LMID request)  or  one  of  the
   following special values:

   LM_ID_BASE
          Load  the  shared object in the initial namespace (i.e., the ap‐
          plication's namespace).

   LM_ID_NEWLM
          Create a new namespace and load the shared object in that  name‐
          space.   The object must have been correctly linked to reference
          all of the other shared objects that it requires, since the  new

   NOTES
   dlmopen() and namespaces

   A link-map list defines an isolated namespace  for  the  resolution  of
   symbols  by  the  dynamic linker.  Within a namespace, dependent shared
   objects are implicitly loaded according to the usual rules, and  symbol
   references are likewise resolved according to the usual rules, but such
   resolution is confined to the definitions provided by the objects  that
   have been (explicitly and implicitly) loaded into the namespace.

   The  dlmopen()  function  permits  object-load isolation—the ability to
   load a shared object in a new namespace without exposing  the  rest  of
   the  application to the symbols made available by the new object.  Note
   that the use of the RTLD_LOCAL flag is not sufficient for this purpose,
   since it prevents a shared object's symbols from being available to any
   other shared object.  In some cases, we may want to  make  the  symbols
   provided  by  a dynamically loaded shared object available to (a subset
   of) other shared objects without exposing those symbols to  the  entire
   application.   This  can  be achieved by using a separate namespace and
   the RTLD_GLOBAL flag.

   The dlmopen() function also can be used  to  provide  better  isolation
   than  the  RTLD_LOCAL  flag.  In particular, shared objects loaded with
   RTLD_LOCAL may be promoted to RTLD_GLOBAL if they are  dependencies  of
   another shared object loaded with RTLD_GLOBAL.  Thus, RTLD_LOCAL is in‐
   sufficient to isolate a loaded shared object except in  the  (uncommon)
   case  where  one  has explicit control over all shared object dependen‐
   cies.

   Possible uses of dlmopen() are plugins where the author of the  plugin-
   loading  framework can't trust the plugin authors and does not wish any
   undefined symbols from the plugin framework to be  resolved  to  plugin
   symbols.  Another use is to load the same object more than once.  With‐
   out the use of dlmopen(), this would require the creation  of  distinct
   copies  of  the  shared  object  file.   Using  dlmopen(),  this can be
   achieved by loading the same shared object file  into  different  name‐
   spaces.

   The glibc implementation supports a maximum of 16 namespaces.