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