I agree with the points you raised regarding the general disadvantages of using static libraries. I am also aware that it would significantly increase the size of the package.
In my particular case I require the itpp static libraries since I need to run the compiled code on a simulation cluster which does not have the shared libraries installed. That's the advantage of static libraries: portability. So far I have been building the library myself, as you mentioned. Anyway, I would rather use the ubuntu packages instead of rebuilding the library myself everytime it is updated. I cannot tell you whether there is a large demand that would justify including the static library in the package. But I can tell you that there is a special appeal in the case of math/simulation libraries, since many people who program using those libraries run their code not on their machines but on simulation clusters. My question would be: What would be the criterion to decide whether or not to include the static library within a development package? In the case of lapack3-dev, atlas3-dev, libfftw3-dev, for example, the static libraries are included within the packages. In my opinion, libitpp-dev would fit into the same class (math/simulation purposes) as those packages. Regarding the adequacy of this matter, do you think it would be more appropriate to take the discussion to the debian mantainers? Thanks, Yuri 2008/7/29 Kumar Appaiah <[EMAIL PROTECTED]> > While I have nothing against generating the static library, it's against > (Debian) policy to generate just a static library alone... That doesn't > apply in this case, since we are considering an additional static > library. > > But about an optional static library, I have just one problem. It > results in duplication of code, and possibly a significant increase in > size of the package. Besides, the purpose of a bug fix in the library > automatically propagating to an executable through dynamic linking is > lost, since static executables have to be rebuilt. > > But, if you still require a static library for your own use, I would > suggest building the package yourself. To the best of my knowledge, this > change will not be made by the Ubuntu maintainer for this package. > (Please correct me if I am wrong). > > Thanks. > > Kumar > > -- > Static version of libitpp is missing from libitpp-dev package > https://bugs.launchpad.net/bugs/239179 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in "libitpp" source package in Ubuntu: New > > Bug description: > The static version of the itpp library (libitpp.a) is missing from the > libitpp-dev Ubuntu package. I see that all the other math libraries - such > as lapack, atlas, fftw3, etc. - have both shared (.so) and static versions > (.a), only that of itpp is missing. Would it be possible to include it? That > would be very useful for itpp programmers that need to run their executables > in machines that do not have the shared libraries. > > What I think that can be done to solve it: > > The itpp library should be recompiled with the "--enable-static" option ( > http://itpp.sourceforge.net/current/installation.html) and the "libitpp.a" > file should be included within the ubuntu packages of both hardy and gutsy > versions. > > Thanks in advance, > Yuri C. B. Silva > -- Static version of libitpp is missing from libitpp-dev package https://bugs.launchpad.net/bugs/239179 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
