Bug 243740

Summary:	11.3 bootstrap GHC compiler fails linking programs on 12.0 ld.lld: error: OSMem.c:(.SUNW_dof+0x160): unrecognized reloc 8
Product:	Base System	Reporter:	Gleb Popov <arrowd>
Component:	bin	Assignee:	Mark Johnston <markj>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	markj, toolchain
Priority:	---	Flags:	koobs: mfc-stable12+ koobs: mfc-stable11-
Version:	11.3-RELEASE
Hardware:	amd64
OS:	Any

Description Gleb Popov freebsd_committer

2020-01-30 19:43:36 UTC

I'm facing a problem with bootstrap GHC (Haskell compiler).

The bootstrap compiler is built on amd64 11.3-RELEASE and is located here: http://arrowd.name/ghc-8.6.3-boot-amd64-freebsd.tar.xz

Now, I'm trying to use it to build GHC on 12.0-RELEASE, however it turns out that it doesn't work on FreeBSD 12. Compiling even simple hello world application results in

/usr/bin/ld.lld: error: OSMem.c:(.SUNW_dof+0x160): unrecognized reloc 8

error.

Steps to reproduce. On FreeBSD 12 amd64 do:

fetch http://arrowd.name/ghc-8.6.3-boot-amd64-freebsd.tar.xz

tar -xvf ghc-8.6.3-boot-amd64-freebsd.tar.xz

cd ghc-8.6.3-boot

./configure --prefix=<someprefix>
gmake install

echo main=print 123 > test.hs
<someprefix>/bin/ghc -v test.hs

Making GHC use ld from binutils package makes the problem go away.

Comment 1 Gleb Popov freebsd_committer

2020-02-02 08:38:45 UTC

Interestingly, the same steps work on 13-CURRENT.

And the link should read http://arrowd.name/ghc-8.6.5-boot-amd64-freebsd.tar.xz

Comment 2 Mark Johnston freebsd_committer

2020-02-03 14:18:46 UTC

This is related to some use of userspace DTrace probes, though I don't know how that gets integrated into GHC.  I suspect the issue is related to r313262.  Since it's a bootstrap compiler, you could presumably work around the issue by simply disabling dtrace?

Comment 3 Gleb Popov freebsd_committer

2020-02-03 14:19:44 UTC

(In reply to Mark Johnston from comment #2)
I already worked it around by using GCC, but I'll also try your suggestion. Thanks.

Comment 4 Mark Johnston freebsd_committer

2020-02-03 19:12:26 UTC

(In reply to Gleb Popov from comment #3)
That makes sense, the issue solved by r313262 was specific to lld.  That revision is also not in 11.3 AFAIK, which is why you're hitting it.

Comment 5 Gleb Popov freebsd_committer

2020-02-04 06:36:50 UTC

Ok, since this is fixed in CURRENT and I managed to workaround it, the PR can be closed?

Comment 6 Mark Johnston freebsd_committer

2020-02-04 16:55:17 UTC

(In reply to Gleb Popov from comment #5)
Yes I think so.

Comment 7 Kubilay Kocak freebsd_committer

2020-02-07 08:21:50 UTC

^Triage: 

 - Consider issue resolved (FIXED), given an associated change (commit) in base r313262 was made. Assign to committer that resolved accordingly.
 - Issue relates to 11.3 built (bootstrap) GHC.  Track Version accordingly. 
 - Track merge (mfc-stable*) flags

Comment 8 Gleb Popov freebsd_committer

2020-02-07 08:23:01 UTC

(In reply to Kubilay Kocak from comment #7)
What's the point of triaging closed PRs?

Comment 9 Kubilay Kocak freebsd_committer

2020-02-07 08:39:55 UTC

(In reply to Gleb Popov from comment #8)

^Triage in this case is just a tag/label we use when commenting on issues when in that role, the bug isn't actually being triaged. Its metadata fields are just being changed to more accurately reflect the final state.

This ensures/helps future viewers of the issue, including our future selves have clarity on that final state. In most cases, this all happens during initial triage or while the bug is in progress.

Comment 10 Kubilay Kocak freebsd_committer

2020-02-07 08:41:04 UTC

(In reply to Kubilay Kocak from comment #9)

P.S Bugmeister is working on being able to make certain changes without the associated email that gets sent out. Unfortunately, Bugzilla doesn't provide this functionality out of the box.