Date: Mon, 20 May 2019 21:10:25 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824 Message-ID: <bug-237068-29464-oNEWOvBxeU@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-237068-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-237068-29464@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=3D237068 --- Comment #20 from Dimitry Andric <dim@FreeBSD.org> --- Ok, bisection shows that your test case is fixed by this commit, which is unfortunately quite huge due to all the changed test coverage: https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;a=3Dcommit;h=3Df= d161d860f1df7140153eab4726705cc3e2727b0 > Define various symbols conditionally in shared libraries >=20 > The values of symbols in shared libraries like _end, _edata, and > __bss_start are generally not that useful outside of the shared > library. This patch defines them conditionally with PROVIDE, since a > shared library might need the local value. An example is glibc ld.so > local access to "_begin", "_etext" and "_end". (ld.so gains access to > the local values by making the references using hidden visibility. > That makes the definitions hidden too.) >=20 > We can't use PROVIDE_HIDDEN in the linker scripts because the shared > library might need the value of the symbol in the executable. An > example is freebsd libc dynamic access to "_end". See also https://sourceware.org/bugzilla/show_bug.cgi?id=3D23161 However, it seems that this fix is is already in binutils 2.32, which is the version of the current port. So I don't really understand why the port also asserts. --=20 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-237068-29464-oNEWOvBxeU>