[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems building trunk on Win32

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-06-14 20:01:10 CEST

Branko Èibej <brane@xbc.nu> wrote on 06/14/2004 01:40:57 PM:

> >Manually correcting these two issues appears to gets me past the
problems
> >and allows everything to build and test.
> >
> >
> "Manually correcting..." duh. There are a zillion different ways to
> build on Windows. Obviously the INSTALL instructions describe only one.
> It's also a bit of a pain that Unixy packages all behave differently on
> Windows. So you need to use a bit of imagination, which I see you have.

Let me take them out of order and start here. My point in posting was
simply to point out areas where the docs for building on Windows could be
clarified. My issues were caused by grabbing newer versions of some
libraries. I do not think that would be an uncommon mistake and since the
newer versions of those libraries seems to be packaged differently, it
might be a good idea for the docs to explicitly steer you away from the
newest versions of those libraries. That is all I meant.

> Not if you use the zlib source distro instead of the prebuilt zlib.dll.
>
> >It also appears that this causes zlib to be dynamically linked to
> >zlib1.dll so that file has to be copied to the Subversion bin folder
with
> >the other executables prior to running the tests.
> >
> >
> Again, not if you use the static library.
>
> Anyway, this is not a Subversion issue, it's a Neon issue.

For now, I have just reverted to version 1.1.4. My guess is that zlib has
changed their packaging and do not provide a static version for download
on the newer versions. Actually, I see thay have some docs on the
changes:

http://www.gzip.org/zlib/DLL_FAQ.txt

>
> >Problem #2: intl.dll (libintl)
> >
> >This appears to be linked with msvcr70.dll so none of the Subversion
> >executables, including the Apache modules, will run unless you have
this
> >DLL on your system and in the PATH.
> >
> >
> And where did you get that intl.dll?

I went to the location specified in the INSTALL document.

http://mirrors.kernel.org/gnu/gettext/

> >
> >
> Use the libintl from the downloads area on subversion.tigris.org.

Thank you, I did not know it was there. At some point it would be nice to
clarify in the INSTALL document how that version of the file ought to be
used in conjunction with the ones it points you to download.

>
> >PS - Personally, I see little benefit from using DLL's on Windows. I
> >think it is only going to lead to problems and Subversion would be
better
> >off if it stuck with statically linking as much as it can.
> >
> >
> Indeed? Why is that? Or rather, why would shared libs be useful
> elsewhere, but not on Windows?
>

Because Windows does not have a central package management system for
installing and managing shared libraries. Therefore, one of the reasons
for using them (space savings) does not happen. Also, another reason
would be that in the case of something like the Neon problem (which I
realize is still statically linked) you could have updated to the fixed
version of the library and all of your applications would get the fix.
Again, Windows users do not do this and have no way of knowing to update
shared libraries, except those provided by Microsoft.

What are the benefits that you see Subversion gaining by using shared
DLL's? I do not like, for example, the way the new system requires DLL's
to be copied to Apache's bin folder so that the modules can run. That
doesn't seem like a kosher way to do things. Perhaps when there is a
formal installer out for 1.1 that is not how it will be done, but that is
how the INSTALL document currently does it.

Thanks for the pointers.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 14 20:03:49 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.