OpenBSD Libs

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenBSD Libs

João Salvatti
Hi all,

I've been working on a project to create a smaller, functional version
of OpenBSD (50MB). One thing that I've noticed while carrying out this
project is that there are four types of libraries, eg:


libssl.a
libssl.so.14.0
libssl_p.a
libssl_pic.a

What I would like to know is why are there four different types of
libraries? Since disk consumption is a
severe constraint, I would like to know which of these are of
paramount importance, mandatory for the proper
system operation.

Thanks in advance for the group's attention.

--
Joco Salvatti
Graduated in Computer Science
Federal University of Para - UFPA - Brazil
E-Mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD Libs

Marti Martinez-2
They're meant for different types of linking -- static, dynamic,
position independent, etc. In general, you need to decide what
executables you're going to run, and figure out which libraries they
depend on.

Take care,
Marti

2009/5/13 Joco Salvatti <[hidden email]>:

> Hi all,
>
> I've been working on a project to create a smaller, functional version
> of OpenBSD (50MB). One thing that I've noticed while carrying out this
> project is that there are four types of libraries, eg:
>
>
> libssl.a
> libssl.so.14.0
> libssl_p.a
> libssl_pic.a
>
> What I would like to know is why are there four different types of
> libraries? Since disk consumption is a
> severe constraint, I would like to know which of these are of
> paramount importance, mandatory for the proper
> system operation.
>
> Thanks in advance for the group's attention.
>
> --
> Joco Salvatti
> Graduated in Computer Science
> Federal University of Para - UFPA - Brazil
> E-Mail: [hidden email]
>
>



--
Systems Programmer, Principal
Electrical & Computer Engineering
The University of Arizona
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD Libs

Hannah Schroeter
In reply to this post by João Salvatti
Hi!

On Wed, May 13, 2009 at 03:34:17PM -0300, Joco Salvatti wrote:
>I've been working on a project to create a smaller, functional version
>of OpenBSD (50MB). One thing that I've noticed while carrying out this
>project is that there are four types of libraries, eg:

>libssl.a
>libssl.so.14.0
>libssl_p.a
>libssl_pic.a

>What I would like to know is why are there four different types of
>libraries? Since disk consumption is a
>severe constraint, I would like to know which of these are of
>paramount importance, mandatory for the proper
>system operation.

In general,
  libfoo.a
    Static library, normal build. Used only when you link a program
    against -lfoo and you either specify static linkage or there's
    no dynamic library available (or you're on an architecture that
    doesn't support dynamic libraries at all).
  libfoo_p.a
    Static library for profiling build (used when you link a program
    with -p or -pg).
  libfoo_pic.a
    Static library, but build from the object files that are compiled
    with -fpic or -fPIC (i.e. the object files that are used to build
    the dynamic library). I don't know whether that's used for linking
    with -lfoo at all (or only if you specify its full pathname).
  libfoo.so.x.y
    Dynamic library. Used for linking with -lfoo unless one of the
    others is used as described above.
    *Also needed at runtime* if a program is linked against it.
    If a program is linked against libfoo.so.x.y, you need
    version x.z with the same x and z >= y.

So bottom line, if you don't intend to compile or (re-)link anything
on your target system, IMO you should be safe to remove the lib*.a
files. You *should* keep the lib*.so.* unless you can be sure that
you don't need any binary that is linked against that library (check
with ldd).

You can of course do test installations e.g. in a chroot environment or
in a virtual machine (e.g. qemu) or on a spare machine where it doesn't
hurt if you break things by removing too much.

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD Libs

João Salvatti
Thanks Hannah.

2009/5/14 Hannah Schroeter <[hidden email]>:

> Hi!
>
> On Wed, May 13, 2009 at 03:34:17PM -0300, Joco Salvatti wrote:
>>I've been working on a project to create a smaller, functional version
>>of OpenBSD (50MB). One thing that I've noticed while carrying out this
>>project is that there are four types of libraries, eg:
>
>>libssl.a
>>libssl.so.14.0
>>libssl_p.a
>>libssl_pic.a
>
>>What I would like to know is why are there four different types of
>>libraries? Since disk consumption is a
>>severe constraint, I would like to know which of these are of
>>paramount importance, mandatory for the proper
>>system operation.
>
> In general,
>  libfoo.a
>    Static library, normal build. Used only when you link a program
>    against -lfoo and you either specify static linkage or there's
>    no dynamic library available (or you're on an architecture that
>    doesn't support dynamic libraries at all).
>  libfoo_p.a
>    Static library for profiling build (used when you link a program
>    with -p or -pg).
>  libfoo_pic.a
>    Static library, but build from the object files that are compiled
>    with -fpic or -fPIC (i.e. the object files that are used to build
>    the dynamic library). I don't know whether that's used for linking
>    with -lfoo at all (or only if you specify its full pathname).
>  libfoo.so.x.y
>    Dynamic library. Used for linking with -lfoo unless one of the
>    others is used as described above.
>    *Also needed at runtime* if a program is linked against it.
>    If a program is linked against libfoo.so.x.y, you need
>    version x.z with the same x and z >= y.
>
> So bottom line, if you don't intend to compile or (re-)link anything
> on your target system, IMO you should be safe to remove the lib*.a
> files. You *should* keep the lib*.so.* unless you can be sure that
> you don't need any binary that is linked against that library (check
> with ldd).
>
> You can of course do test installations e.g. in a chroot environment or
> in a virtual machine (e.g. qemu) or on a spare machine where it doesn't
> hurt if you break things by removing too much.
>
> Kind regards,
>
> Hannah.
>



--
"Se Debugar i a arte de remover bugs, programar i a arte de inserm-los".

Donald E. Knuth.

--
Joco Salvatti
Graduated in Computer Science
Federal University of Para - UFPA - Brazil
E-Mail: [hidden email]