home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / softsys / andrew / 1492 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.6 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!uwm.edu!linac!att!ucbvax!ANDREW.CMU.EDU!rr2b+
  2. From: rr2b+@ANDREW.CMU.EDU (Robert Andrew Ryan)
  3. Newsgroups: comp.soft-sys.andrew
  4. Subject: Static linking ATK apps
  5. Message-ID: <kfIOrpK00WoiR8fEN=@andrew.cmu.edu>
  6. Date: 11 Jan 93 17:27:17 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 48
  11.  
  12. Technical discussion and request for ideas follows, feel free to skip
  13. this message...
  14.  
  15. We are currently working on a mechanism whereby a runapp can be
  16. automagically linked with a given set of classes statically loaded.  (We
  17. are also woring on eliminating the assembly language trampoline code in
  18. the dynamic loading system, and providing dummy dynamic loading
  19. functions for machines without dynamic loading support.)
  20.  
  21. The current scheme modifies the rules for making a .do file to install a
  22. list of the object files used, and a list of the libraries used, and a
  23. list of the classes references by the object files included in the .do. 
  24. (Or which would be if a real .do was being generated.)  A program has
  25. been written which uses this information to construct a list of the
  26. object files and libraries needed given a list of classes which are
  27. desired...  For example supplying the list:
  28.  
  29. eza
  30. xws
  31.  
  32. to this program lists all the object files and libraries needed for the
  33. most basic runapp, and generates an appropriate statload.c.  The
  34. difficulty at this point is that the libraries must be re-ordered by
  35. hand.  (Since depending on what objects are pulled out of library A it
  36. might depend on library B, necessitating library B coming after library
  37. A on the link line.)
  38.  
  39. Currently I am thinking of solving this by having a master list of
  40. libraries (and -L and -l switches) with an associated priority
  41. indicating where the argument should fall in the argument list.  Any
  42. unknown libraries would be placed (in no particular order) before the
  43. known libraries.  There are a few problems with this approach of course.
  44.  First, if there are dependencies between user supplied libraries they
  45. must be added to the master list.  Second,  the dependencies between
  46. libraries may depend on which .o files get pulled out. 
  47.  
  48. The main goal all of this is striving to achieve is eliminating the need
  49. to get dynamic loading working for ATK to be useful on a new platform. 
  50. So ideally the solution to ordering the libraries would be machine/OS
  51. independent.
  52.  
  53. If you have any thoughts on the matter we would be happy to hear them. 
  54. (Probably best just to reply to me, if there is general interest I'll
  55. summarize.)
  56.  
  57. Thanks for any ideas,
  58. -Rob Ryan
  59. Andrew Consortium
  60.