To: <[email protected]>
Cc: "Gregory John Casamento" <[EMAIL PROTECTED]>
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.
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
