| Summary: | @gprel relocation against dynamic symbol in /usr/lib/libobjc.a | ||
|---|---|---|---|
| Product: | Base System | Reporter: | dirk.meyer <dirk.meyer> |
| Component: | ia64 | Assignee: | 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
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 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 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 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] 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 State Changed From-To: open->closed Compile libobjc.a with PIC 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] Responsible Changed From-To: freebsd-ia64->gerald The port maintainer will probably want to know about this and maybe keep tabs on it. |