Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[help]Tutorial resources for packaging shared libs

User discussion about Debian Development, Debian Project News and Announcements. Not for support questions.
Post Reply
Message
Author
jube
Posts: 92
Joined: 2012-04-11 17:30

[help]Tutorial resources for packaging shared libs

#1 Post by jube »

hi
Am packaging some shared libs to support s6 on debian.
And the upstream code uses a very non-standard build system http://www.skarnet.org/software/skalibs/ http://www.skarnet.org/software/skalibs/install.html
so i have to package the libs without the help of auto tools or pkgconfig ,
I have read the debian policy manuals regarding shared libs, and the new maintainer guide, its all great but a bit dry.
Can anyone please point me to a tutorial on the subject and or a similar source package can learn from.
Thanks

Hralgmir
Posts: 48
Joined: 2012-07-16 01:05

Re: [help]Tutorial resources for packaging shared libs

#2 Post by Hralgmir »

Extract from The GNU C Programming Tutorial:

Kinds of library

There are two kinds of library: static libraries and shared libraries. When you link to a static library, the code for the entire library is merged with the object code for your program. If you link to many static libraries, your executable will be enormous.

Shared libraries were developed in the late 1980s to reduce the code size of programs on operating systems like GNU. When you link to a shared library, the library's code is not merged with your program's object code. Instead, stub code is inserted into your object code. The stub code is very small and merely calls the functions in the shared library -- the operating system does the rest. An executable created with a shared library can therefore be far smaller than one created with a static library. Shared libraries can also reduce the amount of memory used.

Although shared libraries seem to have every advantage over static libraries, static libraries are still useful. For example, sometimes you will wish to distribute an executable to people whose computers do not have the libraries that yours does. In that case, you might link to a static version of the libraries. This will incorporate the library functions that you need into your executable, so that it will run on systems that don't have those libraries. (It is also sometimes easier to debug a program that is linked to static libraries than one linked to shared libraries. See Introduction to GDB, for more information.)

The file name for a library always starts with lib and ends with either .a (if it is static) or .so (if it is shared). For example, libm.a is the static version of the C math library, and libm.so is the shared version. As explained above, you must use the -l option with the name of a library, minus its lib prefix and .a or .so suffix, to link that library to your program (except the library glibc, which is always linked). For example, the following shell command creates an executable program called math from the source code file math.c and the library libm.so.

gcc -o math math.c -lm

The shared version of the library is always linked by default. If you want to link the static version of the library, you must use the GCC option --static. The following example links libm.a instead of libm.so.

gcc -o math math.c -lm --static

Type info gcc at your shell prompt for more information about GCC options.

Also from The GNU C Library manual:
Appendix C Installing the GNU C Library

Before you do anything else, you should read the FAQ at http://sourceware.org/glibc/wiki/FAQ. It answers common questions and describes problems you may experience with compilation and installation.

Features can be added to the GNU C Library via add-on bundles. These are separate tar files, which you unpack into the top level of the source tree. Then you give configure the ‘--enable-add-ons’ option to activate them, and they will be compiled into the library.

You will need recent versions of several GNU tools: definitely GCC and GNU Make, and possibly others. See Tools for Compilation, below.

Configuring and compiling: How to compile and test GNU libc.
Running make install: How to install it once you've got it compiled.
Tools for Compilation: You'll need these first.
Linux: Specific advice for GNU/Linux systems.
Reporting Bugs: So they'll get fixed.

This manual has details for installing glibc, which is a (large) shared library. I don't know if any of this is relevant for you. I find these manuals are helpful for a lot of C related things. Good luck with your packaging.

jube
Posts: 92
Joined: 2012-04-11 17:30

Re: [help]Tutorial resources for packaging shared libs

#3 Post by jube »

Thank you very much, very interesting.
Have sucessfully packaged skalibs, my first version is unfortunatly not debian complient ( since it effectivly packages the lib-dev with the lib, a big no-no)
but the second version should be fully debian complient, seperating all binaries, with *-dev packages and all symlinks etc et all.
My main problem came from the very unusual make system, but once got the hang of it it was quite simple.
Debian is a bitch when packaging libs, ok its the only gnu distro to offer what is effectivly a choice of libs from which to compile dependant bins, but that itself seems to be a nightmare.
But hey i chose to package for debian, not moaning , if i was that bothered i would chose arch or something :)

Post Reply