> From: "Nicola Pero" <[EMAIL PROTECTED]> > To: <gnustep-dev@gnu.org> > 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.
Thanks. I changed gnustep-make on latest Mingw to automatically generate something like Gorm.app/Gorm.exe.a which should be equivalent (actually maybe a bit more powerful as it includes functions and such ?) to your libxxx.a. So if you just link your bundles against that file, it should/might work without the need for doing manually the list of classes :-) To link the bundles, you can do something like -- ADDITIONAL_GUI_LIBS += ../../Gorm.app/Gorm.exe.a Anyway, just thought I'd mention it. Thanks _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev