Chapter 10. Files
79
this option enforces symbol resolution at build time, a missing library reference will be caught
early as a fatal build error.
All installed shared libraries should be stripped with
strip   strip unneeded
your lib
(The option
  strip unneeded
makes
strip
remove only the symbols which aren't needed
for relocation processing.) Shared libraries can function perfectly well when stripped, since the
symbols for dynamic linking are in a separate part of the ELF object file.
1
Note that under some circumstances it may be useful to install a shared library unstripped, for
example when building a separate package to support debugging.
Shared object files (often
.so
files) that are not public libraries, that is, they are not meant
to be linked to by third party executables (binaries of other packages), should be installed in
subdirectories of the
/usr/lib
directory. Such files are exempt from the rules that govern
ordinary shared libraries, except that they must not be installed executable and should be
stripped.
2
Packages containing shared libraries that may be linked to by other packages' binaries, but
which for some compelling reason can not be installed in
/usr/lib
directory, may install the
shared library files in subdirectories of the
/usr/lib
directory, in which case they should
arrange to add that directory in
/etc/ld.so.conf
in the package's post installation script,
and remove it in the package's post removal script.
An ever increasing number of packages are using
libtool
to do their linking. The latest
GNU libtools (>= 1.3a) can take advantage of the metadata in the installed
libtool
archive
files (
*.la
files). The main advantage of
libtool
's
.la
files is that it allows
libtool
to store
and subsequently access metadata with respect to the libraries it builds.
libtool
will search
for those files, which contain a lot of useful information about a library (such as library depen 
dency information for static linking). Also, they're essential for programs using
libltdl
.
3
Packages that use
libtool
to create shared libraries should include the
.la
files in the
 dev
package, unless the package relies on
libtool
's
libltdl
library, in which case the
.la
files
must go in the run time library package.
You must make sure that you use only released versions of shared libraries to build your pack 
ages; otherwise other users will not be able to run your binaries properly. Producing source
packages that depend on unreleased compilers is also usually a bad idea.
1
You might also want to use the options
  remove section=.comment
and
  remove section=.note
on both shared libraries and executables, and
  strip debug
on static libraries.
2
A common example are the so called  plug ins , internal shared objects that are dynamically loaded by pro 
grams using
dlopen(3)
.
3
Although
libtool
is fully capable of linking against shared libraries which don't have
.la
files, as it is a
mere shell script it can add considerably to the build time of a
libtool
 using package if that shell script has to
derive all this information from first principles for each library every time it is linked. With the advent of
libtool
version 1.4 (and to a lesser extent
libtool
version 1.3), the
.la
files also store information about inter library
dependencies which cannot necessarily be derived after the
.la
file is deleted.






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

gay web hosting

 

Our partners: PHP: Hypertext Preprocessor Best Web Hosting Java Web Hosting Inexpensive Web Hosting  Jsp Web Hosting

Cheapest Web Hosting Jsp Hosting Cheap Hosting

Visionwebhosting.net Business web hosting division of Web Design Plus. All rights reserved