Bug 71674

Summary:	static libraries cannot be linked when building shared libraries
Product:	Base System	Reporter:	Pete French <pete>
Component:	amd64	Assignee:	freebsd-amd64 (Nobody) <amd64>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	5.3-BETA4
Hardware:	Any
OS:	Any

Description Pete French 2004-09-12 18:40:28 UTC

	The supplied /usr/lib/libobjc.a has been compiled in such a
	way that trying to link when making a shared library gives
	the following error:

	/usr/bin/ld: /usr/lib/libobjc.a(Protocol.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
/usr/lib/libobjc.a: could not read symbols: Bad value

	This did not happen on pre BETA versions. I am unsure as to whether
	the linker has changed or what. This may apply to all the static
	libraries in /usr/lib though! I have tried with libz.a and libufs.a
	with the same error.

Fix: 

Preseumably fix buildworld so that static libraries are compiled
	with -fPIC ? This also applies to static libraries built from
	ports.
How-To-Repeat: 	In this instance I was trying to build the GNUstep base libraries.
	But trying to make a very simple shared library, linking against
	static libraries in /usr/lib, will show it up.

Comment 1 peter 2004-09-30 00:34:03 UTC

This is actually "as designed".  You are not supposed to link a .a file 
into a .so file.  i386 lets you get away with it, but on amd64 it is 
fatal.

However.. it looks like we don't have a libobjc.so anymore.  This 
probably explains your problem...
-- 
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5

Comment 2 David E. O'Brien freebsd_committer

2004-11-01 16:41:30 UTC

State Changed
From-To: open->analyzed

The reasoning for the issue has been determined.

Comment 3 Peter Wemm freebsd_committer

2004-11-29 23:51:58 UTC

State Changed
From-To: analyzed->closed

Committed in 6.x some time ago, and now fixed in RELENG_5 as well. 
The bogus disabling of libobjc.so was reverted for amd64.  The reasons 
for doing it were probably only relevant to i386 back in 1998.

Comment 4 Pascal G. Hofstee 2004-11-30 05:37:40 UTC

As i am occasionally toying around with GNUstep as well ... and
noticed that originally the FreeBSD ports-version of GNUstep
essentially required an actual libobjc.so (and hence required to build
a gcc-3.3.5 iirc and get its libobjc.so from there) .... i have since
noticed that it is indeed possible to build GNUstep on FreeBSD/i386
using just our static libobjc.a

I am wondering though if there is any specific reason for Not
reverting this "bogus" disabling of libobjc.so for i386 as well ?

i recall reading somewhere that certain elements of the Objective-C
runtime would require a dynamic libobjc ... though i don't recall
where i read this at the moment ... and it seems not to really impact
GNUstep's functioning.

But if there is no real reason (besides apprently so called
performance impact .. which i hope may have been improved on since
1998) ... i would definately appreciate this change reverted on i386
as well ... (if only for consistency's sake concerning the libraries
provided by the base system between different FreeBSD architectures)

With kind regards,
  Pascal Hofstee