About libraries - Unix

This is a discussion on About libraries - Unix ; Hi, I'm new to programming in unix. 'bit of confused about naming conventions used with libraries under Unix/Linux. Questions! Q. Does static libraries mean statically-linked libraries. And dynamic libraries mean dynamically-linked libraries. Q. How does shared libraries related to these ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: About libraries

  1. About libraries

    Hi,
    I'm new to programming in unix.
    'bit of confused about naming conventions used with libraries under
    Unix/Linux.
    Questions!

    Q. Does static libraries mean statically-linked libraries. And dynamic
    libraries mean dynamically-linked libraries.

    Q. How does shared libraries related to these two kinds of libraries.
    Can there be static libraries that can be shared. (Obviously dynamic
    or dynamically-linked libraries that are shared makes sense). Does
    static libraries mean the library's object code is complied into the
    client application (which needs to use that library) i.e. the client
    application's executable contains the library code (implying that
    sharing static libraries is not feasible)

    Q. When one writes the famous, trivial program of "Hello World" using
    the printf function, does the standard C library libc used statically
    or dynamically.

    'will highly appreciate any comments regarding the problems.

    Thanks!
    /Ankur.

  2. Re: About libraries

    Ankur wrote:
    > I'm new to programming in unix.
    > 'bit of confused about naming conventions used with libraries under
    > Unix/Linux.
    > Questions!


    > Q. Does static libraries mean statically-linked libraries. And dynamic
    > libraries mean dynamically-linked libraries.


    > Q. How does shared libraries related to these two kinds of libraries.
    > Can there be static libraries that can be shared. (Obviously dynamic
    > or dynamically-linked libraries that are shared makes sense). Does
    > static libraries mean the library's object code is complied into the
    > client application (which needs to use that library) i.e. the client
    > application's executable contains the library code (implying that
    > sharing static libraries is not feasible)


    You got it right. A static (or statically linked) library is nothing
    but a buch of object files put together into a single file (using
    the 'ar' command). If you link against that static library these ob-
    ject files (at least the ones required) get put into the executable.
    So a static library can't be a shared library since it has become
    part of each executable that was linked against it.

    Dynamic (or dynamically linked) libraries, linked against the program
    only when it gets statrted, can be (and normally are) shared between
    different processes - shared and dynamic librry are synonyms. That's
    also reflected in the extensions, '.so' stands for "shared object"
    (while the '.a' stands for 'archive').

    > Q. When one writes the famous, trivial program of "Hello World" using
    > the printf function, does the standard C library libc used statically
    > or dynamically.


    Unless you explicitely link your program against a static library
    the dynamic version will be used. So, unless you made the effort
    to locate a static version of the libc and explicitely linked against
    that your program will use the dynamic version of the library.

    If you use have a shared version of a library, say libXYZ.so, and
    a static version, libXYZ.a, and use a command like

    gcc -o my_prog my_prog.c -lXYZ

    then it gets automatically linked against the shared version. Only
    if no dynamic version of the library exists the static version
    would be used. To get the static version when both exist you have
    to tell the linker explicitely, e.g. by using

    gcc -o my_prog my_prog.c /usr/lib/libXYZ.a

    (basically as if the static library would be just another object
    file).
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

  3. Re: About libraries

    On Aug 10, 6:00*pm, j...@toerring.de (Jens Thoms Toerring) wrote:
    > Ankur wrote:
    > > I'm new to programming in unix.
    > > 'bit of confused about naming conventions used with libraries under
    > > Unix/Linux.
    > > Questions!
    > > Q. Does static libraries mean statically-linked libraries. And dynamic
    > > libraries mean dynamically-linked libraries.
    > > Q. How does shared libraries related to these two kinds of libraries.
    > > Can there be static libraries that can be shared. (Obviously dynamic
    > > or dynamically-linked libraries that are shared makes sense). Does
    > > static libraries mean the library's object code is complied into the
    > > client application (which needs to use that library) i.e. the client
    > > application's executable contains the library code (implying that
    > > sharing static libraries is not feasible)

    >
    > You got it right. A static (or statically linked) library is nothing
    > but a buch of object files put together into a single file (using
    > the 'ar' command). If you link against that static library these ob-
    > ject files (at least the ones required) get put into the executable.
    > So a static library can't be a shared library since it has become
    > part of each executable that was linked against it.
    >
    > Dynamic (or dynamically linked) libraries, linked against the program
    > only when it gets statrted, can be (and normally are) shared between
    > different processes - shared and dynamic librry are synonyms. That's
    > also reflected in the extensions, '.so' stands for "shared object"
    > (while the '.a' stands for 'archive').
    >
    > > Q. When one writes the famous, trivial program of "Hello World" using
    > > the printf function, does the standard C library libc used statically
    > > or dynamically.

    >
    > Unless you explicitely link your program against a static library
    > the dynamic version will be used. So, unless you made the effort
    > to locate a static version of the libc and explicitely linked against
    > that your program will use the dynamic version of the library.
    >
    > If you use have a shared version of a library, say libXYZ.so, and
    > a static version, libXYZ.a, and use a command like
    >
    > gcc -o my_prog my_prog.c -lXYZ
    >
    > then it gets automatically linked against the shared version. Only
    > if no dynamic version of the library exists the static version
    > would be used. To get the static version when both exist you have
    > to tell the linker explicitely, e.g. by using
    >
    > gcc -o my_prog my_prog.c /usr/lib/libXYZ.a
    >
    > (basically as if the static library would be just another object
    > file).
    > * * * * * * * * * * * * * * * *Regards, Jens
    > --
    > * \ * Jens Thoms Toerring *___ * * *j...@toerring.de
    > * *\__________________________ * * *http://toerring.de


    Hi Jens,
    Thanks a lot for your explanation...makes perfect sense to me.
    Here's an excerpt from an article on the topic.
    http://www.ibm.com/developerworks/li.../l-shlibs.html

    "But most shared libraries are dynamically linked. That has several
    further implications. One is that you can't predict in advance at
    which address a function will really be when it's called! (There have
    also been statically linked shared library schemes, such as the one in
    BSD/OS, but they are beyond the scope of this article.) "
    Q. Any idea about that what this article is talking about when it says
    statically linked shared libraries.

    Also, could you please suggest some certification in Linux programming
    thats good for self evaluation and also industry recognized.
    (Brainbench is one that I know of, but not much sure whether its worth
    it).

    Thanks for your help!
    -Ankur

  4. Re: About libraries

    Ankur wrote:
    > Here's an excerpt from an article on the topic.
    > http://www.ibm.com/developerworks/li.../l-shlibs.html


    > "But most shared libraries are dynamically linked. That has several
    > further implications. One is that you can't predict in advance at
    > which address a function will really be when it's called! (There have
    > also been statically linked shared library schemes, such as the one in
    > BSD/OS, but they are beyond the scope of this article.) "
    > Q. Any idea about that what this article is talking about when it says
    > statically linked shared libraries.


    > Also, could you please suggest some certification in Linux programming
    > thats good for self evaluation and also industry recognized.
    > (Brainbench is one that I know of, but not much sure whether its worth
    > it).


    Sorry, can't help you with none of these questions.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

  5. Re: About libraries

    Ankur writes:

    >"But most shared libraries are dynamically linked. That has several
    >further implications. One is that you can't predict in advance at
    >which address a function will really be when it's called! (There have
    >also been statically linked shared library schemes, such as the one in
    >BSD/OS, but they are beyond the scope of this article.) "
    >Q. Any idea about that what this article is talking about when it says
    >statically linked shared libraries.


    statically linked shared libraries were a 'hack' used in SVR3 days
    to provide a form of shared library. They were not PIC, so were
    linked at absolute (non-conflicting, which was a pain to maintain)
    addresses. Once loaded by the kernel, they would be shared by
    all processes using the same static shared library. Because the
    symbols were at persistent addresses, application could be 'statically'
    linked against the shared libraries with all symbols resolved at
    link time (rather than at run-time with modern shared objects).

    scott


  6. Re: About libraries

    On Aug 11, 2:20*am, sc...@slp53.sl.home (Scott Lurndal) wrote:

    > *statically linked shared libraries were a 'hack' used in SVR3 days
    > *to provide a form of shared library. *They were not PIC, so were
    > *linked at absolute (non-conflicting, which was a pain to maintain)
    > *addresses. * *Once loaded by the kernel, they would be shared by
    > *all processes using the same static shared library. *Because the
    > *symbols were at persistent addresses, application could be 'statically'
    > *linked against the shared libraries with all symbols resolved at
    > *link time (rather than at run-time with modern shared objects).
    >
    > scott


    Thanks for the inputs scott.

  7. Re: About libraries

    On Aug 10, 3:58 am, Ankur wrote:

    > Q. Does static libraries mean statically-linked libraries. And dynamic
    > libraries mean dynamically-linked libraries.


    A static library isn't linked at all. It's just an archive of object
    files referenced in a similar manner as shared libraries at link time.

    I believe you're talking about dynamically-loaded libraries, which can
    certainly be statically linked. They're dynamic in the sense that the
    code is kept in the library even after linking and it's loaded when a
    dependent program or other library is loaded for execution.

    > Q. How does shared libraries related to these two kinds of libraries.
    > Can there be static libraries that can be shared. (Obviously dynamic
    > or dynamically-linked libraries that are shared makes sense). Does
    > static libraries mean the library's object code is complied into the
    > client application (which needs to use that library) i.e. the client
    > application's executable contains the library code (implying that
    > sharing static libraries is not feasible)


    Shared libraries are a specific type of dynamically-loaded library.
    Generally each function in a single library will only be loaded into
    memory once, no matter how many process are using it. An example is
    the C library. It doesn't matter how many processes require 'printf';
    the function will only be loaded into memory once and all will use
    it. Not all systems do this because it has some controversies
    associated with it. Linux does use this, however.

    > Q. When one writes the famous, trivial program of "Hello World" using
    > the printf function, does the standard C library libc used statically
    > or dynamically.


    The 'printf' is hard-coded into the C library; it doesn't link to
    *another* library to obtain this function. If *your* program is
    statically linked then it will take the definition of 'printf' from
    the C library, in which case it then belongs to your program and the C
    library is no longer involved. If your program is dynamically linked
    then the 'printf' function is loaded from the C library dynamically.

    Kevin P. Barry

+ Reply to Thread