🚀 go-pugleaf

   After a day of puting out fires in other areas, I came back to this
problem and it turned out quite easy.  The problem was that a
dynamically loaded bundle and the staticly loaded code in an
application resolved external symbols from the same external non-NeXT
C library where the bundle needed many more symbols than the
application.

   Here's what I did...

In Makefile.preamble of the application, I put in

	LLIBS = /usr/local/lib
	OTHER_OFILES = obj/hippo.o
	LIBHIPPO = $(LLIBS)/libhippoNext.a

where libhippoNext.a is the C library in question.

In Makefile.postamble of the applicaton, I put in

	obj/hippo.o : $(LIBHIPPO)
		ld -all_load -r -o $@ $(LIBHIPPO)

This dependency rule forces all of libhippoNeXT.a to be linked
re-locateable into the file obj/hippo.o and since obj/hippo.o has been
declared as an "OTHER_OFILE" everything works.   That is, the application
links without errors due to unresolved sysmbols, and the bundle loads
also without errors due to unresolved symbols.

   Obviously, this is a good solution only if you essentially need all
of the library in the application anyway, which is my case.  The real
answer to the problem is to build a shared library, but nobody but a
few gurus at NeXT know how to build a shared library on a NeXT.

   I have nobody to thank for suggestions or solutions to my question
since I didn't get any via the news group nor by e-mail.   This must
be one of the rare cases where the net didn't come thru.
--
Paul F. Kunz	pfkeb@slac.stanford.edu (NeXT mail ok)
Stanford Linear Accelerator Center, Stanford University
Voice: (415) 926-2884   (NeXT) Fax: (415) 926-3587