Re: GNUstep.gui on OS X 10.3.9, make fails (Gorm fails)

[Bryan Pierce]

Hello Wolfgang!!

Thanks again very, very, much!!
At least now I have managed to get Gorm installed and am on to the
next step :-)

Re-making the base did make a difference

    (*)  Complaints about missing libxml, tls, or cups libraries 
completely dissapeared
    (*)  One new error occurred, but adding the patch back in 
eliminated the error
   /usr/bin/ld: ./obj/RTFConsumer.m.o illegal reference to symbol:     
___objc_class_name_NSConstantString defined in indirectly    
   referenced dynamic library /usr/GNUstep/Local/Library/
   Libraries/./libgnustep-base.dylib.1.18
   collect2: ld returned 1 exit status

    (*)  Adding the patch back fixed the error, so the gui installed 
very cleanly

    (*)  gorm still did not install after reinstalling the base and 
gui, however with the patches you provided the gorm did install without 
errors


Again, Sincere Thanks!!!
Bryan

Wolfgang Lux wrote:
> Bryan Pierce wrote:
>
> > Hello again!
> >
> > Perhaps you would be so kind to help me through one more step...
> > I ran into the same error again while make-ing gorm-1.2.10
> >
> > I thought I might be able to figure out how to translate the patch to 
> > Gorm, but it is apparently beyond my level of
> > expertise.
>
> I guess the problem is that my tip to just reinstall gnustep-make 
> after reconfiguring with --enable-absolute-install-paths was 
> incomplete. You also have to rebuild and reinstall gnustep-base, 
> gnustep-gui, and gnustep-back (i.e., make clean followed by make 
> install) for the dynamic libraries to take notice of the configuration 
> change. If things still do not work out then, see for a patch below.
>
> > This is the error that was produced running make:
> > (there is no configure script)
> > (there were also quite a few warnings previous to the error (see 
> > attatchment) - I don't know how significant they are - they do not 
> > appear to be directly related to the error as fare as I can tell)
> >
> >     Linking library GormCore ...
> >    ld: for architecture ppc
> >    ld: warning can't open dynamic library: 
> > libgnustep-base.dylib.1.18    (checking for undefined symbols may be 
> > affected) (No such file or    directory, errno = 2)
> >    ld: obj/GormInternalViewEditor.m.o illegal reference to 
> > symbol:     _NSFrameRect defined in indirectly referenced dynamic 
> > library /usr/    
> > GNUstep/Local/Library/Libraries/./libgnustep-gui.dylib.0.16
> >    /usr/bin/libtool: internal link edit command failed
> >    make[3]: *** [obj/libGormCore.dylib.1.2.10] Error 1
> >
> >
> > And here are the critical lines of the patch for reference (for 
> > /src/gnustep-gui-0.16.0/TextConverters/RTF/GNUmakefile):
> >    +ifeq ($(findstring darwin, $(GNUSTEP_TARGET_OS)), darwin)
> >    +RTFConverter_BUNDLE_LIBS += -lgnustep-gui $(FND_LIBS) $(OBJC_LIBS)
> >    +endif
> >
> >
> > All I can guess is that I would want to create a patch for 
> > /src/gorm-1.2.10/GormCore/GNUmakefile , and perhaps replacing 
> > RTFConverter_BUNDLE_LIBS with something "Gorm-ish"
>
> Digging out the MacPorts Portfile for Gorm it seems that adding 
> something like
>
> ifeq ($(findstring darwin, $(GNUSTEP_TARGET_OS)), darwin)
> SHARED_LD_POSTFLAGS += -lgnustep-base -lgnustep-gui -lGorm 
> -lGormObjCHeaderParser
> endif
>
> to GNUmakefile in GormCore might do the job. And you'll eventually 
> also need
>
> ifeq ($(findstring darwin, $(GNUSTEP_TARGET_OS)), darwin)
> SHARED_LD_POSTFLAGS += -lGorm -lGormObjCHeaderParser 
> -L../GormObjCHeaderParser/obj -lGormObjCHeaderParser
> endif
>
> in GNUmakefile in GormPrefs in that case. (Don't ask for the magic 
> behind.) All of this is untested, since I have no spare machine to run 
> GNUstep on 10.3.
>
> Wolfgang