Bug 49081

Summary: @gprel relocation against dynamic symbol in /usr/lib/libobjc.a
Product: Base System Reporter: dirk.meyer <dirk.meyer>
Component: ia64Assignee: Gerald Pfeifer <gerald>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description dirk.meyer 2003-03-10 19:20:08 UTC
	libobjc cant be linked to applications.

Fix: 

change complilation options ...
	see PR# ia64/38678
How-To-Repeat: 
e.G. Build ports/lang/gnustep-base
http://bento.freebsd.org/errorlogs/ia64-5-latest/gnustep-base-1.5.2.log

[...]
 Compiling file GSSSLHandle.m ...
 Linking bundle SSL ...
/usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_alloc
/usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_copy
/usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_dispose
gmake[2]: *** [SSL.bundle/ia64/freebsd/gnu-gnu-gnu/SSL] Error 1
gmake[1]: *** [SSL.all.bundle.variables] Error 2
gmake[1]: Leaving directory `/tmp/a/ports/lang/gnustep-base/work/gnustep-base-1.5.2/SSL'
gmake: *** [internal-all] Error 2
*** Error code 2
Comment 1 Marcel Moolenaar 2003-03-10 21:48:30 UTC
On Mon, Mar 10, 2003 at 08:22:00PM +0100, dirk.meyer@dinoex.sub.org wrote:
> 
> >Number:         49081
> >Category:       ia64
> >Synopsis:       @gprel relocation against dynamic symbol in /usr/lib/libobjc.a
[snip]
>  Linking bundle SSL ...
> /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_alloc
> /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_copy
> /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_dispose
> gmake[2]: *** [SSL.bundle/ia64/freebsd/gnu-gnu-gnu/SSL] Error 1
> gmake[1]: *** [SSL.all.bundle.variables] Error 2
> gmake[1]: Leaving directory `/tmp/a/ports/lang/gnustep-base/work/gnustep-base-1.5.2/SSL'
> gmake: *** [internal-all] Error 2
> *** Error code 2
> 
> >Fix:
> 
> change complilation options ...
> 	see PR# ia64/38678

Which ompilation options?

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net
Comment 2 Arun Sharma 2003-03-10 22:53:25 UTC
Marcel Moolenaar <marcel@xcllnt.net> writes:

>  >  Linking bundle SSL ...
>  > /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_alloc
>  > /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_copy
>  > /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_dispose

It seems to be by design:

# pwd
/usr/src/gnu/lib/libobjc
# grep NOPIC Makefile
NOPIC=  works but method lookup slowdown is significant

        -Arun
Comment 3 Marcel Moolenaar 2003-03-10 23:13:26 UTC
On Mon, Mar 10, 2003 at 02:53:25PM -0800, Arun Sharma wrote:
> Marcel Moolenaar <marcel@xcllnt.net> writes:
> 
> >  >  Linking bundle SSL ...
> >  > /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_alloc
> >  > /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_copy
> >  > /usr/bin/ld: /usr/lib/libobjc.a(objects.o): @gprel relocation against dynamic symbol _objc_object_dispose
> 
> It seems to be by design:
> 
> # pwd
> /usr/src/gnu/lib/libobjc
> # grep NOPIC Makefile
> NOPIC=  works but method lookup slowdown is significant
> 

Yes, hence my question. We cannot easily change this without affecting
other platforms (assuming for a moment we're not going to create an
ia64 specific kludge -- not gratuitously that is). At this time the
port is broken for all platforms, because of the fundamental flaw of
linking in non-PIC code in a shared library. The fact that it happens
to work on some architectures does not mean it's not broken. So, either
we change the way we build libobjc.a, or we provide a libobjc_pic.a
just like we do for libc.a, or we create a libobjc.so. For the last two
cases the port has to be changed. For the first case it pessimizes the
library (performance-wise) for the complete (or fully archive) programs.

I think the best solution is to build libobjc.a with -fpic.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net
Comment 4 dirk.meyer 2003-03-11 04:05:40 UTC
Marcel Moolenaar schrieb:,

> > change complilation options ...
> > 	see PR# ia64/38678
> 
> Which ompilation options?

you fixed a similar problem:
http://www.freebsd.org/cgi/query-pr.cgi?pr=38678

State-Changed-By: marcel
State-Changed-When: Wed Oct 23 20:58:12 PDT 2002
State-Changed-Why: 
The problem with the @gprel relocation was related to the fact
that we compiled with short data and without -fpic. As a result,
the compiler assumed it could create @gprel relocations to access
data objects placed in the short data (.sdata or .sbss) sections.
The fix is to disable short data for kernel builds (including
modules).

a) can libobj.a build without "short data"

b) or need the application build without "short data" ?

I found only a "--disable-short-wchar" option ...

kind regards Dirk

- Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
- [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org]
Comment 5 Marcel Moolenaar 2003-03-11 04:29:15 UTC
On Tue, Mar 11, 2003 at 05:05:40AM +0100, Dirk Meyer wrote:
> Marcel Moolenaar schrieb:,
> 
> > > change complilation options ...
> > > 	see PR# ia64/38678
> > 
> > Which ompilation options?
> 
> you fixed a similar problem:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=38678
> 
> State-Changed-By: marcel
> State-Changed-When: Wed Oct 23 20:58:12 PDT 2002
> State-Changed-Why: 
> The problem with the @gprel relocation was related to the fact
> that we compiled with short data and without -fpic. As a result,
> the compiler assumed it could create @gprel relocations to access
> data objects placed in the short data (.sdata or .sbss) sections.
> The fix is to disable short data for kernel builds (including
> modules).
> 
> a) can libobj.a build without "short data"
> b) or need the application build without "short data" ?

To solve this problem: b' :-)

b') build the shared library that links against libobjc without
    "short data".

It's a hack because not using short data pessimizes access sequences
and thus reduces performance.

> I found only a "--disable-short-wchar" option ...

... which is unrelated :-)

The best solution is to build libobjc.so. I did that and it solved
the problem, but exposed another one. If we don't want libobjc.so,
we have to build libobjc.a with PIC, which terribly failed on i386
so that we have to make it ia64 specific to start with (even though
it's theoretically required on all architectures).

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net
Comment 6 Marcel Moolenaar freebsd_committer freebsd_triage 2003-03-17 00:04:14 UTC
State Changed
From-To: open->closed

Compile libobjc.a with PIC
Comment 7 dirk.meyer 2003-04-16 16:16:51 UTC
I run into problems on alpha and sparc too.
The problem is not ia64 specific, as I first assumed.

/usr/libexec/elf/ld: /usr/local/lib/gcc-lib/alpha-portbld-freebsd4.8/3.2.2/libobjc.a(class.o): gp-relative relocation against dynamic symbol _objc_lookup_class

I need the libobjc.so which I get from the gcc32 ports instead.
So the "-PIC" part can be removed safely.

kind regards Dirk

- Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
- [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org]
Comment 8 David E. O'Brien freebsd_committer freebsd_triage 2003-04-16 16:53:32 UTC
Responsible Changed
From-To: freebsd-ia64->gerald

The port maintainer will probably want to know about this and maybe 
keep tabs on it.