Re: Question regarding policy (11.2)
On Thu, Feb 06, 2003 at 01:21:45AM -0700, Ivan E. Moore II wrote:
> "All libraries must have a shared version in the lib* package and a
> static version in the lib*-dev package"
>
> I'm not too keen on providing static versions of libraries [whose]
> intent [is use in] embedded devices.
I'm not too keen on providing static versions at all. I can't remember
I last saw someone use a -dev package for that. People usually need a
-dev package for the .so file and the .h files.
I propose we make an exception:
In general, libraries must have a shared version in the
library package (<package>lib*</package>) and a static
version in the development package (<package>lib*-dev</package>).
The shared version must be compiled with <tt>-fPIC</tt>,
and the static version must not be. In other words, each source
unit (<tt>*.c</tt>, for example, for C files) will need to be
compiled twice.
...changed to...
The shared version of a library must be placed in the library
package, <package>lib*</package>, and it must be compiled with
<tt>-fPIC</tt><footnote>
GCC option for generating position-independent code,
suitable for dynamic linking.
</footnote>.
The static version of a library must be compiled without the
<tt>-fPIC</tt> option. It must be placed in the development
package, normally <package>lib*-dev</package>, but if its size
exceeds the size of the rest of the files in the development
package, it can be placed in a separate package called
<package>lib*-static-dev</package>. It is recommended that the
<package>lib*-dev</package> packages then declare a
<tt>Suggests</tt> or <tt>Recommends</tt> relationship to their
respective <package>lib*-static-dev</package> package.
This change doesn't seem like it would harm the users of static libraries in
a major way (if they noticed that it was missing, they would see the answer
in dpkg -s output or in their frontend). It would help the users who just
want to (re)compile stuff by making them get/install half the bytes.
--
2. That which causes joy or happiness.
Reply to: