en Copyright 2015 Java http://172.16.0.5:8080/history/freebsd-12.1/lib/libc/libc.ldscript#091b8336 Attempt to move the POSIX iconv* symbols out of runtime linker space.FreeBSD systems usually implemented this as a third party module andour implementation hasn't played as nicely with the old way as it couldhave.To that end:* Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix.* Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work.* Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so.* Move the "iconv*" wrapper symbols to libc_nonshared.aThis should solve the runtime ambiguity about which symbols resolveto where. If you compile against the iconv in libc, your runtimedependencies will be unambiguous.Old 9.x libraries and binaries will always resolve against theirlibiconv.so.3 like they did on 9.x. They won't resolve against libc.Old 10.x binaries will be satisified by the .symver helpers.This should allow ports to selectively compile against the libiconvport if needed and it should behave without ambiguity now.Discussed with: kib List of files: /freebsd-12.1/lib/libc/libc.ldscript Sun, 17 Nov 2013 22:52:17 +0000 Peter Wemm <peter@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-12.1/lib/libc/libc.ldscript#54f82841 Turn libc.so into an ld script rather than a symlink pointing to thereal shared object and libssp_nonshared.a.This was the last showstopper that prevented from enabling SSP for portsby default. portmgr@ performed a buildworld which showed no significantbreakage with this patch.Details:On i386 for PIC objects, gcc uses the __stack_chk_fail_local hiddensymbol instead of calling __stack_chk_fail directly [1]. This happennot only with our gcc-4.2.1 but also with the latest gcc-4.8. If youwant the very nasty details, see [2].OTOH the problem doesn't exist on other architectures. It also doesn'texist with Clang as the latter will somehow manage to create thefunction in the object file at compile time (contrary to onlyreferencing it through a symbol that will be brought in at link time).In a perfect world, when an object file is compiled with-fstack-protector, it will be linked into a binary or a DSO with thissame flag as well, so GCC will add libssp_nonshared.a to the linkercommand-line. Unfortunately, we don't control softwares in ports and wemay have such broken DSO. This is the whole point of this patch.You can reproduce the problem on i386 by compiling a source file into anobject file with "-fstack-protector-all -fPIE" and linking itinto a binary without "-fstack-protector".This ld script automatically proposes libssp_nonshared.a along with thereal libc DSO to the linker. It is important to understand that theobject file contained in this library will be pulled in the resultingbinary _only if_ the linker notices one of its symbols is needed (i.e.one of the SSP symbol is missing).A theorical performance impact could be when compiling, but my testingshowed less than 0.1% of difference.[1] For 32-bit code gcc saves the PIC register setup by using __stack_chk_fail_local hidden function instead of calling __stack_chk_fail directly. See comment line 19460 in: src/contrib/gcc/config/i386/i386.c[2] When compiling a source file to an object file, if you use something which is external to the compilation unit, GCC doesn't know yet if this symbol will be inside or outside the DSO. So it expects the worst case and routes the symbol through the GOT, which means additional space and extra relocation for rtld(1). Declaring a symbol has hidden tells GCC to use the optimal route (no GOT), but on the other hand this means the symbol has to be provided in the same DSO (namely libssp_nonshared.a). On i386, GCC actually uses an hidden symbol for SSP in PIC objects to save PIC register setup, as said in [1].PR: ports/138228PR: ports/168010Reviewed by: kib, kan List of files: /freebsd-12.1/lib/libc/libc.ldscript Wed, 12 Jun 2013 21:12:05 +0000 Jeremie Le Hen <jlh@FreeBSD.org>