Subject: Re: building shared libs on NetBSD?
To: David Wetzel <dave@turbocat.de>
From: Jeffrey A Law <law@hurl.cygnus.com>
List: netbsd-help
Date: 03/17/1999 23:44:21
  In message <199903180256.DAA00657@cat.turbocat.de>you write:
  > Hi,
  > 
  > I have a problem with shared objc libs on NetBSD/i386:
  > 
  > gcc -c  -DGNUSTEP_INSTALL_PREFIX=/usr/GNUstep  
  > -DGNUSTEP_TARGET_DIR=\"ix86/netbsd1.3.2\" -DGNUSTEP_TARGET_CPU=\"ix86\"  
  > -DGNUSTEP_TARGET_OS=\"netbsd1.3.2\" -DLIBRARY_COMBO=\"gnu-gnu-gnu-xraw\"  
  > -DGNUSTEP -DGNUSTEP_VERSION=0.5.5 -DGNUSTEP_MAJOR_VERSION=0  
  > -DGNUSTEP_MINOR_VERSION=5  -fPIC  -g -O2 -Wno-import -fgnu-runtime    
  > -I./srcdir-include -I./ix86/netbsd1.3.2    -I. -I/usr/local/include   
  > -I/usr/X11R6/include      -I/nowhere/Headers -o  
  > shared_obj/ix86/netbsd1.3.2/gnu-gnu-gnu-xraw/BinaryCStream.o BinaryCStream.
  > m
  > /var/tmp/cclZ2ckh.s: Assembler messages:
  > /var/tmp/cclZ2ckh.s:11383: Warning: GOT relocation burb:  
  > `__OBJC_CLASS_BinaryCStream' should be global
  > /var/tmp/cclZ2ckh.s:11383: Warning: GOT relocation burb:  
  > `__OBJC_CLASS_BinaryCStream' should be global
Well, I'm not aware of anyone working with ObjC & PIC code generation.

Normally PIC code generation doesn't need any changes to the front-ends, but
once in a while a front-end does something weird and needs to be adjusted
for PIC code generation.

I suspect that's what happening in this case since the x86 backend PIC support
should be solid.

jeff