Date: Mon, 11 Nov 2002 23:53:26 -0600 (CST) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: current@freebsd.org Cc: dfr@nlsystems.com Subject: binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING) Message-ID: <200211120553.gAC5rQFi093274@latour.rsch.comm.mot.com> In-Reply-To: <200211080929.17687.dfr@nlsystems.com> References: <3DCADE51.2090607@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > In the windows world, all this is handled by having a strict list of explicit > symbol exports, either in the source code using syntax extensions or with a > file supplied to the linker. I'm not sure whether binutils supports this kind > of thing but it would allow us to cut down the set of symbols exported from > libc.so. It does. Proof by example: libstdc++.so and libgcc_s.so built from sources included with FSF gcc 3.1 and all forward releases support this feature on FreeBSD. It works fine on FreeBSD 4.7 and 5.0 (with system copy of binutils in both cases). I don't know the exact version of binutils that added this feature but it was before 2.12[.2]. The ld features being used are both symbol versioning and symbol hiding. (Speaking of which, I am reminded to insert this advisement of a related minor issue with the current system compiler:) libstdc++.so as built along with the system compiler does not make use of these features yet on FreeBSD 5.0 since the system-static Makefiles to build the compiler-related libraries have not been updated to account for the feature and many extra symbols are exported as a result. libstdc++.so uses this linker features to present a more stable ABI, no matter the concrete implementation under the hood of the library. I am hoping that the gcc maintainer on the FreeBSD system-side will reconsider this issue before 5.0 is released. FYI, the libstdc++-v3 maintainers on the FSF side are only guaranteeing forward ABI compatibility of any sort if libstdc++.so is built with symbol versioning and symbol hiding. Also, I believe it may be an error to even ship a libstdc++.so unless it is linked against libgcc_s.so (and it currently is not so linked since we don't build libgcc_s.so). As I understand it, if a user of the system compiler attempts to build a stand-alone C++ shared library (i.e. no link against libstdc++.so) but then later uses it in an application that also uses libstdc++.so, EH will fail unless libgcc_s.so was properly built and used. I understand that FreeBSD circa 1996(?) attempted to use a "shared libgcc.so"; libgcc_s.so is similar but different. For one libgcc_s.so is only part of what was libgcc.a; i.e. all code still links against libgcc.a when libgcc_s.so is built and used properly. Regards, Loren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211120553.gAC5rQFi093274>