🚀 go-pugleaf

In article <PFKEB.93Jan20214908@kaon.SLAC.Stanford.EDU>  
pfkeb@kaon.SLAC.Stanford.EDU (Paul F. Kunz) writes:
>    I would appreciate advice on how to best handle the following 
> situation...
> 
>    I have a large body of code with nibs which I've encapsulated in to
> a NXBundle.  The code makes calls to an external library package.  The
> purpose of the bundle is so that a number of other applications can
> load this bundle rather than compiling and linking their own copies of
> the source code.  These other applications also link against the same
> external library, but far fewer members of the library.
> 
I have a similar question.  When distributing a custom Palette I
need to distribute a library of the object code along with the
Palette, which I believe is a bundle.   The Palette contains my
custom subclass of IBPalette (MyIBPalette) along with other classes I have
created.  The palette (bundle) also contains nib and tiff files
that the other classes need.  To get those resources I use 

bundle = [NXBundle bundleForClass: [MyIBPalette class]];
[bundle getpath:buf forResource .....]

in the code for the other classes.

To create the library I took all the object code files from the 
   palette and used ar and ranlib to create a library which I link in 
   with the application using the custom Palette.  This gives the message:

/bin/ld: Undefined symbols:
objc_class_name_IBInspector
_IBObjectPboardType
objc_class_name_IBPalette

Questions:

a) Is there another library other than the standard -lMedia_s -lNeXT_s
   that could be linked to solve this problem (I could not find one.)

b) Should I not be using the class MyIBPalette to be the class 
   "holding" the bundle for all the custom palette resources since
    the application will not require the IBInspectors and IBPalette
    classes during execution.  It only needs them when running
    Interface Builder.

Ed Nicolson
nicolson@robotics.berkeley.edu

   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