From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris McGee <sirnewton_01@yahoo.ca>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <63814C1E-B962-4221-B9E6-2B1BBDBB55F7@yahoo.ca>
Date: Thu,  8 Sep 2016 20:48:21 -0400
References: <91091b7db7ee00347dfc22bd3d9ab312@hamnavoe.com>
In-Reply-To: <91091b7db7ee00347dfc22bd3d9ab312@hamnavoe.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Linker and duplicate symbols
Topicbox-Message-UUID: 9ce108f6-ead9-11e9-9d60-3106f5b1d025

Thanks Richard,

I traced it down to a symbol being brought in from libc that brought in othe=
r symbols that collided with ones on the kernel.

Btw, with your latest changes I have merged them in with the latest 9front a=
nd its running on my Pi 1 and Pi 2.

Only weird problem is when I do fshalt -r. My pi2 goes unstable with panics o=
n reboot. Cold reset brings it back to normal.

Does your latest code work on Pi zero? I don't yet have one to test it.

Chris

On Sep 2, 2016, at 12:11 PM, Richard Miller <9fans@hamnavoe.com> wrote:

>> Is it that the linker prefers a symbol from a .5 file over the .a file?
>=20
> I believe it's supposed to pick the first one it finds.  Object files and
> libraries are processed in the order in which they appear on the command l=
ine.
> On my system proc.5 appears before libc.a in the ld command, and libc.a(sl=
eep.5)
> doesn't contain any symbols other than sleep, so there should be no reason=

> for ld to pull it in from the library.
>=20
>=20