From owner-freebsd-current  Sun Apr 22 12:24: 6 2001
Delivered-To: freebsd-current@freebsd.org
Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5048937B422; Sun, 22 Apr 2001 12:24:00 -0700 (PDT)
	(envelope-from sobomax@FreeBSD.org)
Received: from notebook.vega.com (dialup9-29.iptelecom.net.ua [212.9.228.29])
	by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id WAA26531;
	Sun, 22 Apr 2001 22:23:55 +0300 (EEST)
	(envelope-from sobomax@FreeBSD.org)
Date: Sun, 22 Apr 2001 22:23:55 +0300 (EEST)
Message-Id: <200104221923.WAA26531@ipcard.iptcom.net>
To: sobomax@FreeBSD.org, current@FreeBSD.org, obrien@FreeBSD.org
From: Maxim Sobolev <sobomax@FreeBSD.org>
Reply-To: sobomax@FreeBSD.org
Subject: Re: --whole-archive ld(1) option doesn't work
X-Mailer: Pygmy (v0.5.5)
In-Reply-To: <200104221219.PAA93082@ipcard.iptcom.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sun, 22 Apr 2001 15:19:10 +0300 (EEST), Maxim Sobolev wrote:
> I've noticed that the --whole-archive option doesn't work in -CURRENT and
> 4-STABLE. Among other things it makes impossible to build openssl from ports
> (yeah, I know that one should use ssl from /usr/src, but that's not a point).
> 
> Attached testcase and log exose the problem in question.

It seems that the problem is not in ld(1), but in gcc(1) front-end. On
a link stage it passes two -lgcc directives, that confuses the linker:

$ cc -v -shared -o /tmp/libfoo.so.1 -Wl,--whole-archive /usr/lib/libz.a
Using builtin specs. gcc version 2.95.3 20010315 (release)
/usr/libexec/elf/ld -m elf_i386 -Bshareable -o /tmp/libfoo.so.1
/usr/lib/crti.o /usr/lib/crtbeginS.o -L/usr/libexec/elf -L/usr/libexec
-L/usr/lib --whole-archive /usr/lib/libz.a -lgcc -lgcc /usr/lib/crtendS.o
/usr/lib/crtn.o /usr/lib/libgcc.a(_pure.o): In funcc -v -shared -o
/tmp/libfoo.so.1 -Wl,--whole-archive /usr/lib/libz.action
`__pure_virtual': _pure.o(.text+0x0): multiple definition of `__pure_virtual'
/usr/lib/libgcc.a(_pure.o)(.text+0x0): first defined here
/usr/lib/libgcc.a(_exit.o)(.data+0x0): multiple definition of `_exit_dummy_decl'
/usr/lib/libgcc.a(_exit.o)(.data+0x0): first defined here

I found the the workaround for this problem is to add -nodefaultlibs
and -lgcc, i.e. the following works:

$ cc -v -nodefaultlibs -shared -o /tmp/libfoo.so.1 -Wl,--whole-archive
/usr/lib/libz.a -lgcc
Using builtin specs.
gcc version 2.95.3 20010315 (release)
 /usr/libexec/elf/ld -m elf_i386 -Bshareable -o /tmp/libfoo.so.1
/usr/lib/crti.o /usr/lib/crtbeginS.o -L/usr/libexec/elf -L/usr/libexec
-L/usr/lib --whole-archive /usr/lib/libz.a -lgcc /usr/lib/crtendS.o
/usr/lib/crtn.o
$ 

Looks like a gcc(1) bug to me.

-Maxim

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message