Date: Fri, 20 Jun 2014 17:12:47 +0000 From: bugzilla-noreply@freebsd.org To: mono@FreeBSD.org Subject: [Bug 190851] lang/mono build broken when using binutils from ports Message-ID: <bug-190851-23699-FAtLHOZdxc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-190851-23699@https.bugs.freebsd.org/bugzilla/> References: <bug-190851-23699@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190851 --- Comment #3 from John Hein <z7dr6ut7gs@snkmail.com> --- Here are some more details. Base OS is using binutils 2.17.50 (+ freebsd changes) or freebsd 8.x is using a base binutils based on 2.15. Latest port is binutils 2.24. I think the check that is causing this build failure was added to binutils in 2.21-ish time frame. See also: https://sourceware.org/bugzilla/show_bug.cgi?id=13255 Both mono/mini/ldscripts & ldscripts.mono have: . . local: *; . . Because of this when ld(1) from binutils 2.24 tries to link object files to create a binary executable, it notices that crt1.o has __progname defined and libc.so has an undefined reference to __progname. Normally this link together just fine, but via the linker script we've told it that all symbols that are not the explicitly listed global symbols are local symbols. So ld(1) refuses to resolve the libc->crt1.o dependency for __progname and spits out the 'local symbol is reference by DSO' message. I'm pondering the best way to fix this. Maybe: (1) add __progname & environ to globals list in the linker script like my previous attached patch. This is specific to platforms like freebsd that define __progname (and environ) in one object file (crt1.o) and reference it in a DSO (libc.so). (2) remove 'local: *' from the linker script used for producing programs (as opposed to shared libs) - namely mono/mini/ldscripts.mono. We don't really care whether symbols are marked global or local in the executable images, just the shared libs. (3) modify Makefile.am (&/or Makefile.in for the mono port since lang/mono doesn't currently re-run the auto* tools) to not use the linker script for the executables, just for the shared libs. I think I prefer (2) and that seems most likely acceptable for upstream (although I haven't opened a bug there yet). -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-190851-23699-FAtLHOZdxc>