On Sat, Sep 5, 2009 at 4:51 PM, D.J. Heap <djheap_at_gmail.com> wrote:
> On Sat, Sep 5, 2009 at 3:42 PM, Robert Dailey<rcdailey_at_gmail.com> wrote:
> [snip]
> >
> > Yes, I can understand the frustration now. However, this is as far as I
> can
> > help. APR's static libraries need to be including these dependencies in
> its
> > library, ideally, to avoid any unnecessary complication on SVN's side.
> > Linking static libraries with other static libraries has proven to have
> its
> > own set of problems, but in some circumstances it can save some work. The
> > patch, as is, just so happens to work well for the libraries themselves.
> If
> > the SVN project is still not linking, then it needs to personally include
> > those dependencies you speak of. How to do this will require a bit more
> work
> > on the python scripts, but I don't have the time to try to get SVN
> building.
> > My goal was to get the svn libraries compiling against the correct
> > libraries. Perhaps someone else can pick this up where I left off and get
> > SVN working?
> > Sorry to half-ass this, but it's starting to go beyond the problem I
> > originally wanted to solve.
>
>
> Sure, no problem. This is very likely why it is not supported much in
> the first place. As far as I recall, you're the first person to
> actually want a totally static build (ie, statically linking apr as
> well) on Windows. Subversion used to only supply static libraries
> (although it still dynamically linked to apr as it does now) and it
> seemed like everyone hated it. There was much rejoicing when the
> dynamic libraries were added.
The problem is, dynamic libraries don't save you much, in fact they make
things more complicated. Static or not, at some point translation units will
need symbols at the link phase. If something uses the Win32 API, then at
some point in the build process you will need to link against the OS
libraries. The only difference between static and dynamic is the point at
which you must supply the dependencies. Dynamic libs are less flexible.
Dynamic libraries, in my opinion, are unnecessarily complex. They are extra
files that you have to manage in your distribution and it makes build
systems more complex (Because your build script has to keep track of shared
libraries and copy them around to target directories for debugging
purposes). There are only a few reasons why I would ever use shared
libraries:
- If I plan to dynamically swap out code modules while the application is
running.
- If the DLL is COM-based and backwards compatibility is important.
- The DLL was being shared by multiple applications in my distribution
and/or different languages.
For my purposes, static libs are fine because I have no requirements that
would prevent me from using them. Why bother with extra files to keep track
of when you don't have to?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2391376
Received on 2009-09-06 00:11:26 CEST