home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / next / programm / 8267 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.1 KB  |  53 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!stanford.edu!unixhub!kaon.SLAC.Stanford.EDU!pfkeb
  3. From: pfkeb@kaon.SLAC.Stanford.EDU (Paul F. Kunz)
  4. Subject: Re: NXBundles and external libraries
  5. In-Reply-To: pfkeb@kaon.SLAC.Stanford.EDU's message of Thu, 21 Jan 1993 05:49:11 GMT
  6. Message-ID: <PFKEB.93Jan22202833@kaon.SLAC.Stanford.EDU>
  7. Lines: 40
  8. Sender: news@unixhub.SLAC.Stanford.EDU
  9. Organization: Stanford Linear Accelerator Center
  10. References: <PFKEB.93Jan20214908@kaon.SLAC.Stanford.EDU>
  11. Date: Sat, 23 Jan 1993 04:28:37 GMT
  12.  
  13.    After a day of puting out fires in other areas, I came back to this
  14. problem and it turned out quite easy.  The problem was that a
  15. dynamically loaded bundle and the staticly loaded code in an
  16. application resolved external symbols from the same external non-NeXT
  17. C library where the bundle needed many more symbols than the
  18. application.
  19.  
  20.    Here's what I did...
  21.  
  22. In Makefile.preamble of the application, I put in
  23.  
  24.     LLIBS = /usr/local/lib
  25.     OTHER_OFILES = obj/hippo.o
  26.     LIBHIPPO = $(LLIBS)/libhippoNext.a
  27.  
  28. where libhippoNext.a is the C library in question.
  29.  
  30. In Makefile.postamble of the applicaton, I put in
  31.  
  32.     obj/hippo.o : $(LIBHIPPO)
  33.         ld -all_load -r -o $@ $(LIBHIPPO)
  34.  
  35. This dependency rule forces all of libhippoNeXT.a to be linked
  36. re-locateable into the file obj/hippo.o and since obj/hippo.o has been
  37. declared as an "OTHER_OFILE" everything works.   That is, the application
  38. links without errors due to unresolved sysmbols, and the bundle loads
  39. also without errors due to unresolved symbols.
  40.  
  41.    Obviously, this is a good solution only if you essentially need all
  42. of the library in the application anyway, which is my case.  The real
  43. answer to the problem is to build a shared library, but nobody but a
  44. few gurus at NeXT know how to build a shared library on a NeXT.
  45.  
  46.    I have nobody to thank for suggestions or solutions to my question
  47. since I didn't get any via the news group nor by e-mail.   This must
  48. be one of the rare cases where the net didn't come thru.
  49. --
  50. Paul F. Kunz    pfkeb@slac.stanford.edu (NeXT mail ok)
  51. Stanford Linear Accelerator Center, Stanford University
  52. Voice: (415) 926-2884   (NeXT) Fax: (415) 926-3587
  53.