Bug 190851
| Summary: | lang/mono build broken when using binutils from ports | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Don Lewis <truckman> | ||||||
| Component: | Individual Port(s) | Assignee: | freebsd-mono (Nobody) <mono> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | jcfyecrayz, romain | ||||||
| Priority: | --- | ||||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
|
Description
Don Lewis
2014-06-10 01:03:22 UTC
Over to mainainters. Created attachment 143916 [details]
hack loader script to work with binutils-2.24 port's ld(1)
I can confirm the same behavior (8-stable/i386, same ports).
Another workaround is attached (add to port as file/patch-mono-mini).
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). Created attachment 143970 [details] disable local symbol wildcarding for linking executables (vs. libs) This diff implements (2) described in comment 3. I submitted a bug upstream: https://bugzilla.xamarin.com/show_bug.cgi?id=20762 This has been a recurring problem, from time to time a similar PR is opened, the proposed fix (adding __progname + environ) often breaked build on my system (recent FreeBSD ususaly), and without being in capacity of reproducting the problem, PR got stall then closed :-(. Thank you for your deep inspection of the situation. I'll try the proposed patch ASAP. A commit references this bug: Author: romain Date: Wed Jun 25 09:40:16 UTC 2014 New revision: 359212 URL: http://svnweb.freebsd.org/changeset/ports/359212 Log: Unbreak on FreeBSD 8.4. PR: ports/190851 Submitted by: truckman Changes: head/lang/mono/Makefile head/lang/mono/files/patch-mono-mini-ldscript.mono |