home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / programm / 5664 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  4.4 KB
  1. Xref: sparky comp.unix.programmer:5664 comp.sys.sun:9 comp.compilers:2016 comp.unix.wizards:5201
  2. Newsgroups: comp.unix.programmer,comp.sys.sun,comp.compilers,comp.unix.wizards
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
  4. From: twa@neuromancer.bellcore.com (Tom Ackenhusen)
  5. Subject: Programmaticly controlled dynamic linking
  6. Reply-To: twa@neuromancer.bellcore.com (Tom Ackenhusen)
  7. Organization: Bell Communications Research
  8. Date: Fri, 11 Dec 1992 20:42:08 GMT
  9. Approved: compilers@iecc.cambridge.ma.us
  10. Message-ID: <92-12-048@comp.compilers>
  11. Followup-To: comp.unix.programmer
  12. Keywords: linker, sparc, question, comment
  13. Sender: compilers-sender@iecc.cambridge.ma.us
  14. Lines: 74
  15.  
  16. This is a detailed question concerning dynamic linking and programmatic
  17. control of the dynamic linker.  Any help would be greatly appreciated.
  18.  
  19. I am trying to define wrapper functions for functions in a vendor-supplied
  20. library.  I want to do this in such a way that I do not have to alter any
  21. existing source code which calls the vendor library, I do not have to
  22. duplicate all functions in the vendor library, and I still have access
  23. (from my library routines) to all of the vendor library routines.  I need
  24. to do this so that I can provide additional behavior for selected routines
  25. in the vendor library without having to alter the installed base of
  26. application code which uses the library (with the possible exception of
  27. makefile changes and re-linking).  This requires my wrapper functions to
  28. have identical names as the vendor functions that my functions enhance.
  29. (I am actually trying to insert my code between application code and the
  30. standard X Toolkit API.)
  31.  
  32. I think I may have an approach, but I'm not sure if it would work.  It
  33. requires using a programmatic interface to the dynamic linker.  In my
  34. case, since I am on Suns, I would be using the dlopen/dlsym/dlclose
  35. routines.  This approach also requires that the vendor library be
  36. available for dynamic loading (a shared library).  What I want to try is
  37. to have my intermediate library code use dlopen to load the vendor library
  38. and dlsym() to get handles to the vendor's functions to use to invoke the
  39. functions.
  40.  
  41. (If it matters, my exact development environment is SunOS 4.1.1 on a
  42. SPARCstation 2 using Sun's bundled compiler.  I am willing to change to
  43. another compiler/linker/etc. if necessary.)
  44.  
  45. Does anyone know if this is possible?  Has anyone done it?  Is there a
  46. good source of information on using the dlopen() routines and the linker?
  47.  
  48. The problems I can predict are:
  49.  
  50. 1) Since my library won't duplicate all functions in the vendor library,
  51.    the linker will have to load the vendor library symbol table at compile
  52.    time.  This will result in duplicate symbol definitions.  How can I
  53.    avoid this?  Can I designate some list of symbols to ignore duplicate
  54.    definitions for?
  55.  
  56. 2) Is it possible to call functions using the information returned
  57.    from a dlsym() call?  How?
  58.  
  59. 3) How can I insure that the run-time loading of the vendor library
  60.    follows the same rules that it would if it were a normal dynamically-
  61.    loaded library (using LD_LIBRARY_PATH and observing the shared object
  62.    version number system, etc.)?  Are there available routines to do this,
  63.    or will I need to duplicate this functionality with my code?
  64.  
  65. 4) The vendor library must always be a shared object (or in a form
  66.    that can be opened by dlopen()).  How restrictive is this
  67.    constraint?
  68.  
  69. Also, if this approach worked, could the same approach be applied to most
  70. UNIX environments which support dynamic linking?  I know the code wouldn't
  71. be portable, but do most UNIX environments make this approach possible?
  72.  
  73. Please respond to me through e-mail.  I will summarize the information I
  74. receive if there is interest.
  75.  
  76. Thanks.
  77. -- 
  78. Tom Ackenhusen            VITAL Computer contractor at
  79. twa@ctt.bellcore.com        Bell Communications Research
  80. [When I needed to do this, I wrote a little program that changed the names
  81. of the symbols in the original shared library, then wrote wrappers under
  82. the original name that called the old code using the changed name.  I had
  83. applications I couldn't recompile, so I also needed to patch the apps to
  84. add my new library to the list that they linked at startup time.  All of
  85. the library data formats are well documented, so I did the whole thing in
  86. an afternoon. -John]
  87. -- 
  88. Send compilers articles to compilers@iecc.cambridge.ma.us or
  89. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  90.