gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nicola Pero
Subject: Re: More Windows stuff ... Gorm works ... sort of
Date: Tue, 22 Mar 2005 05:40:18 +0000 (GMT)

> 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.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]