On Wed, Nov 29, 2006 at 01:15:33AM +1030, n0dalus wrote: > Going through the main points on > http://people.redhat.com/drepper/no_static_linking.html I don't see a > lot of justification for the complete removal of static linking > support in Fedora. So far the only proposed alternative to static > linking is this approach of sticking the .so files in with the program > and using LD_LIBRARY_PATH in a script -- which is almost just as bad > as static linking. You misunderstood part of this thread. The bundling of shared libraries with the app was a suggested alternative for those requiring bit-wise identical results from numerical apps, it is definitely not meant as a general way how ISVs should ship their programs. Those requiring bit-wise identical result intentionally don't care about security (they even depend on bug-to-bug compatibility), they probably even can't live with randomization (but that can be turned off with setarch), etc. For programs which don't have such requirements (the vast majority), an analysis of the libraries the (dynamically linked) program links against (or dlopens) is needed. There are libraries which keep ABI stable and maintain backwards compatibility (either through symbol versioning or by strictly only adding new symbols, never changing the semantics of old entry points or removing symbols), there are libraries that do that mostly, but from time to time bump SONAME, there are libraries which change their ABI (and bump SONAME) often. For the first category (e.g. glibc, libX11), the rule of thumb is link dynamically, don't include the libraries with your program, compile and link against the oldest version you still want to support. Say by compiling/linking against glibc 2.2.0, you should cover RHL7.0 and higher (and other Fall 2000 and later released distros). I think we can re-add compat-glibc, perhaps containing several sets of headers and dummy link-only libs, to FE, then you just use some compat-gcc* together with this compat-glibc* and can build even on contemporary distros programs that run on older as well as contemporary distros. For the second category (e.g. libstdc++ especially if you want to support even really prehistoric distros), you sometimes want to optionally bundle a shared library with your program, but e.g. at install time of the program check whether the system doesn't provide that library (same SONAME and either as old or newer than what you are bundling) and in that case use the system library rather than your own - the OS vendor will then take care of security fixes in it, bugfixes too, etc. Though I guess most of the distro vendors these days have libstdc++ 3.2/3.3 and 3.4/4.0/4.1 libs around, similarly with other libs (crypto, etc.). Then there are shared libraries which have ABI of the day, in that case either bundle your own shared library always or link .a library statically (-Wl,-Bstatic -lbfd -Wl,-Bdynamic), example here is e.g. libbfd. Jakub -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
