Re: Linking libraries

Discussion in 'C++' started by Ian Collins, Jul 2, 2010.

  1. Ian Collins

    Ian Collins Guest

    On 07/ 3/10 10:31 AM, Paavo Helde wrote:
    >
    > Agreed. DLL sharing is useful only if the DLL is really stable. In
    > Windows world this would be kernel32.dll and such. On Linux the C runtime
    > also qualifies, but not in Windows as there are so many uncompatible
    > versions.


    While true, that's a bit too narrow in scope. On my platform of choice
    (Solaris), static libraries are largely historical. On most if not all
    Unix derived systems, shared libraries are the way to go.

    --
    Ian Collins
     
    Ian Collins, Jul 2, 2010
    #1
    1. Advertising

  2. Ian Collins

    Trifle Menot Guest

    On Sat, 03 Jul 2010 10:47:54 +1200, Ian Collins <>
    wrote:

    >On 07/ 3/10 10:31 AM, Paavo Helde wrote:
    >>
    >> Agreed. DLL sharing is useful only if the DLL is really stable. In
    >> Windows world this would be kernel32.dll and such. On Linux the C runtime
    >> also qualifies, but not in Windows as there are so many uncompatible
    >> versions.

    >
    >While true, that's a bit too narrow in scope. On my platform of choice
    >(Solaris), static libraries are largely historical. On most if not all
    >Unix derived systems, shared libraries are the way to go.


    You go that way. I'll go the other way.


    --
    Web mail, POP3, and SMTP
    http://www.beewyz.com/freeaccounts.php
     
    Trifle Menot, Jul 3, 2010
    #2
    1. Advertising

  3. Ian Collins

    James Kanze Guest

    On Jul 2, 11:47 pm, Ian Collins <> wrote:
    > On 07/ 3/10 10:31 AM, Paavo Helde wrote:
    > > Agreed. DLL sharing is useful only if the DLL is really
    > > stable. In Windows world this would be kernel32.dll and
    > > such. On Linux the C runtime also qualifies, but not in
    > > Windows as there are so many uncompatible versions.


    > While true, that's a bit too narrow in scope. On my platform
    > of choice (Solaris), static libraries are largely historical.
    > On most if not all Unix derived systems, shared libraries are
    > the way to go.


    For the system libraries (e.g. libc.so); I don't think that
    Sun/Oracle even deliver statically linkable versions any more.
    In some ways, the same holds for Windows. The difference is
    that Windows does provide the statically linkable versions, and
    that not all of the dynamically linkable versions are bundled
    with the OS, so you sometimes have to ship them as well.

    For anything above the system level (including the C++ standard
    library), I'd go with static linking, unless I specifically
    needed some particular behavior of dynamic linking (choosing the
    version of the library at runtime, for example).

    --
    James Kanze
     
    James Kanze, Jul 4, 2010
    #3
  4. Ian Collins

    Ian Collins Guest

    On 07/ 4/10 11:59 PM, James Kanze wrote:
    > On Jul 2, 11:47 pm, Ian Collins<> wrote:
    >> On 07/ 3/10 10:31 AM, Paavo Helde wrote:
    >>> Agreed. DLL sharing is useful only if the DLL is really
    >>> stable. In Windows world this would be kernel32.dll and
    >>> such. On Linux the C runtime also qualifies, but not in
    >>> Windows as there are so many uncompatible versions.

    >
    >> While true, that's a bit too narrow in scope. On my platform
    >> of choice (Solaris), static libraries are largely historical.
    >> On most if not all Unix derived systems, shared libraries are
    >> the way to go.

    >
    > For the system libraries (e.g. libc.so); I don't think that
    > Sun/Oracle even deliver statically linkable versions any more.
    > In some ways, the same holds for Windows. The difference is
    > that Windows does provide the statically linkable versions, and
    > that not all of the dynamically linkable versions are bundled
    > with the OS, so you sometimes have to ship them as well.
    >
    > For anything above the system level (including the C++ standard
    > library), I'd go with static linking, unless I specifically
    > needed some particular behavior of dynamic linking (choosing the
    > version of the library at runtime, for example).


    Interesting, I prefer dynamic linking. Mainly because there are fewer
    link order dependencies. I also tend to have several applications based
    on common libraries running on any given system.

    I don't know about windows, but a lot of my debug tools (memory access
    checking, profiling) can be selectively enabled on a per-module basis.

    --
    Ian Collins
     
    Ian Collins, Jul 4, 2010
    #4
  5. Ian Collins

    James Kanze Guest

    On Jul 4, 9:40 pm, Ian Collins <> wrote:
    > On 07/ 4/10 11:59 PM, James Kanze wrote:
    > > On Jul 2, 11:47 pm, Ian Collins<> wrote:
    > >> On 07/ 3/10 10:31 AM, Paavo Helde wrote:
    > >>> Agreed. DLL sharing is useful only if the DLL is really
    > >>> stable. In Windows world this would be kernel32.dll and
    > >>> such. On Linux the C runtime also qualifies, but not in
    > >>> Windows as there are so many uncompatible versions.

    >
    > >> While true, that's a bit too narrow in scope. On my platform
    > >> of choice (Solaris), static libraries are largely historical.
    > >> On most if not all Unix derived systems, shared libraries are
    > >> the way to go.


    > > For the system libraries (e.g. libc.so); I don't think that
    > > Sun/Oracle even deliver statically linkable versions any more.
    > > In some ways, the same holds for Windows. The difference is
    > > that Windows does provide the statically linkable versions, and
    > > that not all of the dynamically linkable versions are bundled
    > > with the OS, so you sometimes have to ship them as well.


    > > For anything above the system level (including the C++ standard
    > > library), I'd go with static linking, unless I specifically
    > > needed some particular behavior of dynamic linking (choosing the
    > > version of the library at runtime, for example).


    > Interesting, I prefer dynamic linking. Mainly because there
    > are fewer link order dependencies. I also tend to have
    > several applications based on common libraries running on any
    > given system.


    I've never found link order dependencies a problem; if you've
    a clean design, there should be no cycles, and the order of
    dependencies is well established. There may be issues with
    third party libraries, if they don't document the dependencies,
    but that only has to be solved once.

    > I don't know about windows, but a lot of my debug tools
    > (memory access checking, profiling) can be selectively enabled
    > on a per-module basis.


    Debugging is one possible advantage of dynamic linking. Most
    systems do provide some sort of hooking for function calls
    accross dynamic object interfaces. But it doesn't seem worth
    the extra cost in deployment.

    --
    James Kanze
     
    James Kanze, Jul 5, 2010
    #5
  6. Ian Collins

    jhendrix58 Guest

    On Jul 5, 8:32 am, James Kanze <> wrote:
    > On Jul 4, 9:40 pm, Ian Collins <> wrote:
    >
    >
    >
    > > On 07/ 4/10 11:59 PM, James Kanze wrote:
    > > > On Jul 2, 11:47 pm, Ian Collins<>  wrote:
    > > >> On 07/ 3/10 10:31 AM, Paavo Helde wrote:
    > > >>> Agreed. DLL sharing is useful only if the DLL is really
    > > >>> stable. In Windows world this would be kernel32.dll and
    > > >>> such. On Linux the C runtime also qualifies, but not in
    > > >>> Windows as there are so many uncompatible versions.

    >
    > > >> While true, that's a bit too narrow in scope.  On my platform
    > > >> of choice (Solaris), static libraries are largely historical.
    > > >> On most if not all Unix derived systems, shared libraries are
    > > >> the way to go.
    > > > For the system libraries (e.g. libc.so); I don't think that
    > > > Sun/Oracle even deliver statically linkable versions any more.
    > > > In some ways, the same holds for Windows.  The difference is
    > > > that Windows does provide the statically linkable versions, and
    > > > that not all of the dynamically linkable versions are bundled
    > > > with the OS, so you sometimes have to ship them as well.
    > > > For anything above the system level (including the C++ standard
    > > > library), I'd go with static linking, unless I specifically
    > > > needed some particular behavior of dynamic linking (choosing the
    > > > version of the library at runtime, for example).

    > > Interesting, I prefer dynamic linking.  Mainly because there
    > > are fewer link order dependencies.  I also tend to have
    > > several applications based on common libraries running on any
    > > given system.

    >
    > I've never found link order dependencies a problem; if you've
    > a clean design, there should be no cycles, and the order of
    > dependencies is well established.  There may be issues with
    > third party libraries, if they don't document the dependencies,
    > but that only has to be solved once.
    >
    > > I don't know about windows, but a lot of my debug tools
    > > (memory access checking, profiling) can be selectively enabled
    > > on a per-module basis.

    >
    > Debugging is one possible advantage of dynamic linking.  Most
    > systems do provide some sort of hooking for function calls
    > accross dynamic object interfaces.  But it doesn't seem worth
    > the extra cost in deployment.
    >
    > --
    > James Kanze


    For what it is worth,

    1) I agree with the points favoring static linking over dynamic
    linking,
    2) I agree with the rationales for the special case of dynamically
    linking to libc.so (or to its Windows equivalents),
    3) I agree with the point that a good design will eliminate cycles and
    therefore problems with order dependencies.

    Regarding the question of whether to create a number of project
    specific libraries or just create a number of objs and link those: I
    recommend creating a number of project specific libraries. This
    recommendation is based more on my personal development practices,
    which emphasizes unit testing.

    I like to do automatic hierarchical unit testing during the build. By
    this I mean that the libraries are built and unit tested in creasing
    order of dependency. The makefile should be rigged such that the
    build halts when a library's unit test fails.

    I recommend that each library be cohesive and be loosely coupled with
    the other libraries. I recommend that each lib be roughly no more
    complex than a small program. Each library should have its own unit
    test that executes after the library is built.

    My rationale for recommending a hierarchy of small libraries over a
    single large library is that it reduces unit test effort. It is
    easier to unit test functionality that exists in a library located at
    the bottom of a hierarchy of libraries than it is to unit test the
    same functionality when it is located at the "bottom" of a single,
    very large library.

    is difficult to unit test functionality that exists at the bottom of a
    hierarc
     
    jhendrix58, Jul 5, 2010
    #6
  7. Ian Collins

    Ian Collins Guest

    On 07/ 6/10 12:32 AM, James Kanze wrote:
    > On Jul 4, 9:40 pm, Ian Collins<> wrote:
    >> On 07/ 4/10 11:59 PM, James Kanze wrote:

    >
    >>> For anything above the system level (including the C++ standard
    >>> library), I'd go with static linking, unless I specifically
    >>> needed some particular behavior of dynamic linking (choosing the
    >>> version of the library at runtime, for example).

    >
    >> Interesting, I prefer dynamic linking. Mainly because there
    >> are fewer link order dependencies. I also tend to have
    >> several applications based on common libraries running on any
    >> given system.

    >
    > I've never found link order dependencies a problem; if you've
    > a clean design, there should be no cycles, and the order of
    > dependencies is well established. There may be issues with
    > third party libraries, if they don't document the dependencies,
    > but that only has to be solved once.


    I had all sorts of problems with link order dependencies before I
    swapped to dynamic linking. But that was 20 odd years ago and my
    approach to design has changed somewhat over the intervening decades!

    At least with dynamic linking link order dependencies are one less
    problem to solve.

    I must admit I'm surprised you favour static linking given your focus on
    reducing coupling. Dynamic linking is the build equivalent of
    minimising coupling in code.

    >> I don't know about windows, but a lot of my debug tools
    >> (memory access checking, profiling) can be selectively enabled
    >> on a per-module basis.

    >
    > Debugging is one possible advantage of dynamic linking. Most
    > systems do provide some sort of hooking for function calls
    > accross dynamic object interfaces. But it doesn't seem worth
    > the extra cost in deployment.


    I don't really see an extra cost in deployment. I guess it may be
    platform specific, but modern packaging systems solve any dependency
    problems (I guess that's the payback for not having to consider link
    order dependencies).

    The real cost often isn't in deployment, a one off activity, but in
    support. If like me you have a number of applications running on
    systems, patching a bug in a shared library only requires an update to
    that library, not to all the applications that use it.

    --
    Ian Collins
     
    Ian Collins, Jul 6, 2010
    #7
  8. Ian Collins

    James Kanze Guest

    On Jul 6, 12:05 am, Ian Collins <> wrote:
    > On 07/ 6/10 12:32 AM, James Kanze wrote:
    > > On Jul 4, 9:40 pm, Ian Collins<> wrote:
    > >> On 07/ 4/10 11:59 PM, James Kanze wrote:


    [...]
    > I must admit I'm surprised you favour static linking given your focus on
    > reducing coupling. Dynamic linking is the build equivalent of
    > minimising coupling in code.


    It's a trade-off. I guess in the end, I like the idea of
    knowing the exact program image my user is complaining about.
    Mixed versions of dynamic objects is just one more thing which
    can go wrong.

    > >> I don't know about windows, but a lot of my debug tools
    > >> (memory access checking, profiling) can be selectively enabled
    > >> on a per-module basis.


    > > Debugging is one possible advantage of dynamic linking. Most
    > > systems do provide some sort of hooking for function calls
    > > accross dynamic object interfaces. But it doesn't seem worth
    > > the extra cost in deployment.


    > I don't really see an extra cost in deployment. I guess it may be
    > platform specific, but modern packaging systems solve any dependency
    > problems (I guess that's the payback for not having to consider link
    > order dependencies).


    > The real cost often isn't in deployment, a one off activity, but in
    > support. If like me you have a number of applications running on
    > systems, patching a bug in a shared library only requires an update to
    > that library, not to all the applications that use it.


    Yes. And suppose that patch makes the library incompatible with
    the other programs which use it. I've seen too many cases of
    code which runs with only one specific version of a dynamic
    object. And where patching one application breaks three others.
    And I like to test what the client is running (in addition to
    unit tests). If I'm releasing a new version of X, and it uses
    three different dynamically loaded objects, each with three
    different versions in the field, that means 81 different
    combinations to test. If I link statically, I only have to test
    the resulting executable, and I know the program the client runs
    is the one I've tested.

    Up to a point, of course. I don't statically link libc, and
    I can't begin to cover all of the different versions and
    combinations of patches which I might encounter.

    All of which is to say that there isn't one perfect solution.
    If you're a library provider, there are probably a fair number
    of cases where providing a dynamically loaded object is
    preferrable, *provided* you can freeze your interface, so that
    clients can effectively link against any version they might
    find. If you're providing an application in the form of an
    executable, the cases where you'd want to provide part of the
    application as a shared object seem rather rare, however: mostly
    cases where you load the library explicitly (the human language
    interface, for example).

    --
    James Kanze
     
    James Kanze, Jul 6, 2010
    #8
  9. Ian Collins

    Öö Tiib Guest

    On 9 juuli, 19:37, "io_x" <> wrote:
    > "James Kanze" <> ha scritto nel messaggionews:...
    >
    >
    >
    > > On Jul 6, 12:05 am, Ian Collins <> wrote:
    > >> I don't really see an extra cost in deployment.  I guess it may be
    > >> platform specific, but modern packaging systems solve any dependency
    > >> problems (I guess that's the payback for not having to consider link
    > >> order dependencies).

    >
    > >> The real cost often isn't in deployment, a one off activity, but in
    > >> support.  If like me you have a number of applications running on
    > >> systems, patching a bug in a shared library only requires an update to
    > >> that library, not to all the applications that use it.

    >
    > > Yes.  And suppose that patch makes the library incompatible with
    > > the other programs which use it.  I've seen too many cases of
    > > code which runs with only one specific version of a dynamic
    > > object.  And where patching one application breaks three others.

    >
    > for me the way is only doing one correct routine,
    > and for doing that => only one .dll and all program execute
    > routine from that


    Then you are a god? I would expect at least less buggy English on such
    case. :-D

    Seriously, have you seen anything useful without several errors? I
    have seen nothing.

    When i link statically to library then i can work around the errors in
    particular version and not use the buggy features of it.

    There are no chance i can work around errors in next version before i
    have it. Next version contains new errors. About 50% of error fixes
    cause other errors. So ... in next version they most probably broke
    the features i used for to fix the ones i did avoid using.

    > > And I like to test what the client is running (in addition to
    > > unit tests).  If I'm releasing a new version of X, and it uses
    > > three different dynamically loaded objects, each with three
    > > different versions in the field, that means 81 different
    > > combinations to test.  If I link statically, I only have to test
    > > the resulting executable, and I know the program the client runs
    > > is the one I've tested.

    >
    > you would say it is better to have 100 version of the same routine
    > that not are 100% correct? and each other differ ?


    That is what we have. Learn to live with it. Instead of 1 perfect
    being we are about 7 billions of people. Each with their weirdnesses
    and problems. Software is mostly written by persons who are bit above
    average bright, but they do some little things in it wrong every time.
     
    Öö Tiib, Jul 9, 2010
    #9
  10. Ian Collins

    James Kanze Guest

    On Jul 9, 6:00 pm, Öö Tiib <> wrote:
    > On 9 juuli, 19:37, "io_x" <> wrote:


    > When i link statically to library then i can work around the
    > errors in particular version and not use the buggy features of
    > it.


    The real question is whether you want to test your software
    yourself, or let your users test it. If you link statically,
    the program your users use is the one you tested. If you link
    dynamically, it might not be.

    --
    James Kanze
     
    James Kanze, Jul 12, 2010
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Pein

    Linking native libraries in Win2K

    Martin Pein, Oct 9, 2003, in forum: Java
    Replies:
    4
    Views:
    2,116
    Martin Pein
    Oct 14, 2003
  2. LinuxN00b

    Statically Linking Libraries

    LinuxN00b, Aug 6, 2003, in forum: C++
    Replies:
    1
    Views:
    373
    Thomas Matthews
    Aug 6, 2003
  3. Bernd Geiser

    Linking libraries with local symbols

    Bernd Geiser, Aug 18, 2003, in forum: C++
    Replies:
    1
    Views:
    376
    Artie Gold
    Aug 18, 2003
  4. Thato
    Replies:
    2
    Views:
    446
    Jack Klein
    Aug 18, 2004
  5. paddy
    Replies:
    1
    Views:
    349
    Mike Wahler
    Oct 4, 2004
Loading...

Share This Page