home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / aix / 9639 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.0 KB
  1. Path: sparky!uunet!munnari.oz.au!mel.dit.csiro.au!yarra!yarrina.connect.com.au!codex!bpja
  2. From: bpja@codex.oz.au (Brett Adam)
  3. Newsgroups: comp.unix.aix
  4. Subject: HARD problem with shared libraries (long)
  5. Message-ID: <1992Sep14.115643.837@codex.oz.au>
  6. Date: 14 Sep 92 11:56:43 GMT
  7. Sender: bpja@codex.oz.au
  8. Reply-To: bpja@codex.oz.au
  9. Organization: Codex Software Development Pty Ltd
  10. Lines: 72
  11.  
  12. To any AIX shared library 'gurus' out there ....
  13.  
  14.  
  15. Part of a product I'm porting at the moment requires that a number of routines  
  16. in the standard shared library, libc.a, be 'enhanced'. The idea is that this be  
  17. done is such a way that existing (compiled) software automatically gain access  
  18. to the new enhanced functionality.
  19.  
  20. In particular, the functions 'getpwent', 'gethostbyname' and others need to be  
  21. extended with a 'pre-patch' to consult an alternative database BEFORE falling  
  22. back to their previous behaviour. (Which means the replacement routine must  
  23. call the original routine)
  24.  
  25.  
  26. Our strategy on the Sun was simple:
  27.  
  28. Unarchive libc.a
  29.  
  30. Take the existing routines, and rename them in the library. Thus, getpwent()  
  31. becomes tnewpteg() or similar.
  32.  
  33. Write new getpwent() that does extra work, then calls tnewpteg() if required,  
  34. to get the old behaviour.
  35.  
  36. Wrap our new object files and the original objects with renamed routines back  
  37. up into a shared libc.a.
  38.  
  39. This works admirably - on the Sun.
  40.  
  41.  
  42. Under AIX 3.2, we hit a stumbling block. Whilst the bind tool is _very_  
  43. powerful, and can do all the renaming for us easily, we cannot package the  
  44. shared library back up once again.
  45.  
  46. In particular, a load line such as the following produces an output file that  
  47. grows without bounds - until it fills the entire disk!!
  48.  
  49.  
  50.   ld -r -brename:.getpwent,.tnewpteg shr.o -o shr.o.new -bM:SRE
  51.  
  52. (The libc.a member shr.o seems to contain the routines that need enhancing)
  53.  
  54. I've spent a _lot_ of time experimenting with using the bind tool interactively  
  55. to try and find a way to achieve what we want. No luck.
  56.  
  57. We've even written an xcoffpatch tool that makes the substitutions directly in  
  58. the XCOFF shr.o file. Works fine, but we cannot wrap up our new objects with  
  59. the shr.o object without hitting the infite file problem.
  60.  
  61. I've tried all manner of import/export scenarios to no avail.
  62.  
  63. Indeed, when I _think_ that I have a new libc.a constructed, upon installation,  
  64. all existing tools simply output "Killed" when executed. (Pretty clear  
  65. indication that the new libc.a is bogus).
  66.  
  67.  
  68. The point:
  69.  
  70. Does ANYONE out there have any experience with this sort of approach?
  71. Does anyone have any better ideas about how to achieve the desired result?
  72. (short of obtaining the entire source to libc.a and re-building it ourselves!)
  73. (of course, if that option is available.... :-) )
  74.  
  75.  
  76. Thanks in hopeful anticipation,
  77.  
  78.  
  79. -- 
  80. ---------------------------------------------------------------
  81. Brett Adam                 Xedoc Software Development Pty. Ltd.
  82. NeXTMail: bpja@codex.oz.au                  AppleLink: AUST0335
  83. (Preferred.)                                 (Only if you must) 
  84.