On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote: > "Steve M. Robbins" <steve@sumost.ca> writes: > > >> As I've come to understanding, nowadays many libraries doesn't allow > >> trivial static linkage, > > > > I don't follow; it's generally as simple as using -static on > > the link line. Pretty trivial. > > Which a) might not be simple to get the build system to do and b) is far > from enough to build a static library. I see that we read the original comment differently. I was reacting to the claim "libraries can't be LINKED TO statically". You read it as "libraries can't be BUILT statically". With your reading, I agree that it's not *always* possible. At the end of my remarks, I agreed with the statement A development package should provide a static library *if possible*. > >> and that it's generally not recommended to > >> link statically in packages. > > > > That is completely separate from the question of whether Debian should > > provide static libraries for users to link with. I don't see that it > > should have any bearing. > > I think the better question is wether static linking even works at > all? > > There are many libraries that use plugins, most importantly libc6. The > probability that you invoke one of the plugin functions in libc6 in any > non trivial programm is high and then the static binary crashes and > burns if the dynamic libc6 on the system is incompatible. And if the > dynamic libc6 on the system is compatible then why would you ever want > to link it static? > > Static linking of libc6 basically never makes sense. The same can be > said for many other libs. Possibly that's true for many libraries, but surely not all of them. > On the other hand, even assuming the build system supports a static lib, > building a static lib means building the library twice. That complicates > the rules file and packaging. It also increases package size. Our priorities are our users. There are many things that complicate life for a packager, but are important to do because they benefit our users. > >> Thus I think we should consider updating the policy to either > >> specify that a development package should provide a static library > >> if possible, > > > > I agree with this sentiment. > > > > > > -Steve > > Given the cost that involves and that nobody has screamed about it in > the last 10 years I would opt for rephrasing it to "as needed". The > would reflect the current practice best. I don't accept either of your premises. For my part, I haven't surveyed our users to understand how important static linking is. However, I do know of communities that routinely build static binaries in order to guarantee reproducibility of data analysis results over time -- part of the so-called Reducible Research movement [1]. Secondly, in my packaging of libraries -- including the monstrous Boost -- I supply static libs whereever possible, not "as needed". This is how I've always read the current policy and I believe that phrase best reflects current practice. Regards, -Steve [1] http://www.rrplanet.com/reproducible-research-librum/
Attachment:
signature.asc
Description: Digital signature