Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: Linking libraries

Reply
Thread Tools

Re: Linking libraries

 
 
Ian Collins
Guest
Posts: n/a
 
      07-02-2010
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
 
Reply With Quote
 
 
 
 
Trifle Menot
Guest
Posts: n/a
 
      07-02-2010
On Sat, 03 Jul 2010 10:47:54 +1200, Ian Collins <(E-Mail Removed)>
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

 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      07-04-2010
On Jul 2, 11:47 pm, Ian Collins <(E-Mail Removed)> 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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      07-04-2010
On 07/ 4/10 11:59 PM, James Kanze wrote:
> On Jul 2, 11:47 pm, Ian Collins<(E-Mail Removed)> 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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-05-2010
On Jul 4, 9:40 pm, Ian Collins <(E-Mail Removed)> wrote:
> On 07/ 4/10 11:59 PM, James Kanze wrote:
> > On Jul 2, 11:47 pm, Ian Collins<(E-Mail Removed)> 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
 
Reply With Quote
 
jhendrix58
Guest
Posts: n/a
 
      07-05-2010
On Jul 5, 8:32*am, James Kanze <(E-Mail Removed)> wrote:
> On Jul 4, 9:40 pm, Ian Collins <(E-Mail Removed)> wrote:
>
>
>
> > On 07/ 4/10 11:59 PM, James Kanze wrote:
> > > On Jul 2, 11:47 pm, Ian Collins<(E-Mail Removed)> *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








 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      07-05-2010
On 07/ 6/10 12:32 AM, James Kanze wrote:
> On Jul 4, 9:40 pm, Ian Collins<(E-Mail Removed)> 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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-06-2010
On Jul 6, 12:05 am, Ian Collins <(E-Mail Removed)> wrote:
> On 07/ 6/10 12:32 AM, James Kanze wrote:
> > On Jul 4, 9:40 pm, Ian Collins<(E-Mail Removed)> 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
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      07-09-2010
On 9 juuli, 19:37, "io_x" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> ha scritto nel messaggionews:(E-Mail Removed)...
>
>
>
> > On Jul 6, 12:05 am, Ian Collins <(E-Mail Removed)> 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.

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.

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-12-2010
On Jul 9, 6:00 pm, Öö Tiib <(E-Mail Removed)> wrote:
> On 9 juuli, 19:37, "io_x" <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
c++ non-lang tuts, but on linking, libraries, workspaces and includes paddy C++ 1 10-04-2004 02:59 AM
Linking third party Libraries Thato C++ 2 08-18-2004 03:01 AM
Linking native libraries in Win2K Martin Pein Java 4 10-14-2003 09:08 PM
Linking libraries with local symbols Bernd Geiser C++ 1 08-18-2003 08:18 PM
Statically Linking Libraries LinuxN00b C++ 1 08-06-2003 08:18 PM



Advertisments