Re: More Windows stuff ... Gorm works ... sort of

[Jeremy Bettis]

----- Original Message ----- 
From: "Nicola Pero" <address@hidden>
To: <address@hidden>
Cc: "Gregory John Casamento" <address@hidden>
Sent: Monday, March 21, 2005 5:32 PM
Subject: More Windows stuff ... Gorm works ... sort of

> Unfortunately Windows (and other platforms I think) requires all symbols
> in a bundle to be resolved when the bundle is linked.  So having the
> bundle depend on symbols in the application which is supposed to be
> loading them is not a particularly good way of helping the building
> process.

I added this to the makefile of my main app to deal with this:
internal-all::libottrclasses.a

libottrclasses.a: $(GNUSTEP_OBJ_DIR)/ottrclasses.o
$(AR) $(ARFLAGS) $(AROUT)$@ $<

ottrclasses.c:$(GNUSTEP_OBJ_DIR)/OttrApp.exe
rm -f $(GNUSTEP_OBJ_DIR)/ottrclasses.o
objdump.exe -t *.subproj/$(GNUSTEP_OBJ_DIR)/subproject.o 
$(GNUSTEP_OBJ_DIR)/*.o | egrep '(sec  [1-9])' | grep __objc_class_name_  | 
sed -e 's/.*___objc_class_name_/long __objc_class_name_/' -e 's/$$/ = 0;/' | 
sort -u >ottrclasses.c

Then I link all my bundles against libottrclasses.a, and all is good.  The 
reason this works is because the compiler emits a usage of the symbol 
__objc_class_name_CLASSNAME for every use of a class, but it is not actually 
ever used at runtime.  I think the purpose is to ensure that classes get 
linked in from static libs.  So I fake out the linker by linking against 
this useless stub library, the symbols get resolved with dummies, and the 
runtime doesn't care, so it works.