You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <Ma...@softlanding.com> on 2004/06/14 16:05:06 UTC
Problems building trunk on Win32
I am testing building the latest trunk on Win32. I am using the
instructions found in the file INSTALL, and am using the batch file
included in ..\build\win32 to run the build.
Problem #1: zlib
There is a zlib version 1.2.1 that has been available for quite a while.
It is packaged quite different from 1.1.4 and the instructions, as is,
will not work with 1.2.1. I think the instructions should either be
updated to use 1.2.1, or should be modified to acknowledge that 1.2.1
exists but that you should still use 1.1.4.
I was able to use 1.2.1 by copying the file SVN\zlib\lib\zdll.lib to
SVN\zlib\zlibstat.lib (note the rename). And also by copying the header
files in SVN\zlib\include to SVN\zlib.
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.
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.
I am not sure where I got this DLL, but perhaps I downloaded too new a
version? If that is the case the docs should steer you away from that. I
believe I got this DLL from one of the following:
gettext-runtime-0.13.bin.woe32.zip
gettext-tools-0.13.bin.woe32.zip
libiconv-1.9.1.bin.woe32.zip
Manually correcting these two issues appears to gets me past the problems
and allows everything to build and test.
Thanks
Mark
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Monday 14 June 2004 23.09, SteveKing wrote:
...
> Can you _guarantee_ that the older client still works?
I believe that the vendor of shared libs are responsible for making
usable DLLs. _I_ can't guarantee that older clients will work but I
assume that people are doing their best when making shared libs and
clients.
> I also like to remind you of the problems we already have with the
> iconv library: due to the APR_ICONV_PATH env variable all clients
> already use (have to use) the same lib, even if it was installed by
> another client. And you followed the thread on the TSVN mailing list
> about that too...
You are right about this and you convinced me to place msvcrt71.dll to
its own folder (when Subversion is compiled with VC7). I still belive
you are right here.
You said (from the TSVN list):
> ... Too many times my computer crashed because someone thought
> that his dll was better than the already installed
This is absolutly correct and I listened to you.
However: -I believe that we are trying to provide _one_ set of DLLs
related to Subversion here.
> So for me this won't be an option and TSVN will never be part of that.
> I'd rather work on real bugs in my program than having to deal with
> issues arising from incompatible dlls. I will also patch the iconv lib
> for the next release of TSVN so that it won't use the APR_ICONV_PATH
> variable anymore - I don't see any other way to get rid of the
> reported problems.
I also believe that you are an excellent and visonary programmer with a
well developed sence of both internal and external (GUI) parts of
software.
Some of your warnings, predictions and suggestions has been "overseen"
the last two-three years (everyone here has been "turned down" from time
to time), but that's not because "anyone don't listen to you".
People may have another vues, they might not understand what you are
talking about or simply not have time (or not even care :-).
TSVN is probably the most successfull Subversion project and probably
_the_ reason that the Windows community will use Subversion at large.
So Please, don't fork anything, that's a double effort! Dealing with
incompatible dlls are time consuming, I think you can help us to make
sure that the dlls will remain compatible!
So continue to warn, suggest and do what you do and continue to make
wonderful programs and software!
Jostein
--
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by SteveKing <st...@gmx.ch>.
> The famous "dll hell" is and always was the result of incorrect
> packaging and not paying attention to details. There is no difference
> between Unix and Windows in this respect.
Sure, to break break something someone has to make a mistake. But you're
making it too easy by just saying that it is the result of incorrect
packaging. Much too often programs broke because one dll changed only
slightly (a bugfix) and was tested against one or two programs, but the
third program broke because of this bugfix. I've seen that many times.
> > The %CommonProgramFiles% location is intended for software vendors who
> > ship whole suites which use all the same libs (e.g. adobe, macromedia,
> > ms, ...) but which all programs are tested against those libs.
> > MS even has introduced a mechanism in XP (and will be improved in
> > Longhorn) which allows to have several dlls with the same name but
> > with different versions to reside inside the same folder. Only that
> > way it can be assured that a program only uses those dlls it really
> > knows.
>
> AFAIK that's true of .NET assemblies, not ordinary DLLs.
No. Normal dlls can have that too (on XP). The commctrl.dll is one famous
example. You have to add a manifest to your programs resources to make it
use the newer version which has uses the XP-look on the controls - otherwise
the old version of that dll is used (which has the same name).
> > Imagine Subversion 2.0 comes out and the dll's still have the same name.
>
> They won't, by definition. They'll change from libsvn_foo-1.dll to
> libsvn_foo-2.dll.
Ok, so at least that won't be a problem.
> > I also like to remind you of the problems we already have with the
> > iconv library: due to the APR_ICONV_PATH env variable all clients
> > already use (have to use) the same lib, even if it was installed by
> > another client. And you followed the thread on the TSVN mailing list
> > about that too...
>
> AFAIK _that_ particular problem was caused by TSVN not installing the C
> runtime where every other app expects it.
True. But TSVN installs itself the recommended way! If other apps expect
TSVN to install the C runtime in the windows system folder then that's not
TSVN's fault. Even MS recommends to _not_ install those files there but in
the program directory where the program itself gets installed - and that's
what TSVN does.
So you can see: even though we already try to follow all rules of deploying
a program there's a problem because some programs/libs expect otherwise.
> > So for me this won't be an option and TSVN will never be part of that.
> > I'd rather work on real bugs in my program than having to deal with
> > issues arising from incompatible dlls. I will also patch the iconv lib
> > for the next release of TSVN so that it won't use the APR_ICONV_PATH
> > variable anymore - I don't see any other way to get rid of the
> > reported problems.
>
> I do. It's very simple. Don't live in a world of your own. Coordinate
> these things with the core project. I'm sure we can define an
> installation scheme for the libraries and all clients that will make
> them work together.
Can you guarantee that really _all_ clients will follow the rules? I can't.
> Really, this is ridiculous. If you're going to fork APR-iconv for TSVN
> -- a crazy scheme if I ever saw one, it's one of the most stable parts
> of APR -- you may as well fork SVN itself, for all the good it does us.
I have no intention to fork SVN. But I have to admit that I sometimes was
close to doing that (remember how long it took until the .svn folders got
hidden on windows?).
And no, I don't just fork other projects. First I try to convince the devs
there to include another function or change the API slightly so that it will
for me too. But if that doesn't happen then what other option do I have?
BTW: I mentioned the problems which will arise by apr-iconv using the
APR_ICONV_PATH env variable more than a year ago. Nobody believed me,
nothing was done. Now we have a problem. So tell me, what should I do?
Waiting another year and hope in a change in apr-iconv so it doesn't use
that env variable anymore? I don't have that much time...
> I proposed to introduce a well-defined interface to the (upcoming)
> Subversion core installation for other clients. Our strict API
> guarantees allow us to do this. You can either help with this effort in
> such a way that it benefits TSVN as well, or you can go your own way.
Even your strict API rules can guarantee that a client installs the library
correctly. May I remind you that even the subversion client once installed a
_broken_ iconv library?
> It's your decision. But if you decide against helping with a common
> infrastructure because of some "dll hell" FUD, well, that's tough,
> you'll be duplicating work that others could be doing for you.
This is no FUD. This is real.
> (Funny, I'd been considering getting "svn status -N" --
> svn_client_status, in fact -- to work a bit better, so that TSVN could
> have less performance trouble with the overlay icons. Now I wonder if I
> should bother.)
Don't worry about that. There are other bugs (e.g. when committing deleted
nested folders non-recursively) which affect TSVN much more.
Stefan
--
+++ Jetzt WLAN-Router f�r alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH?] APR_ICONV_PATH was: Problems building trunk on Win32
Posted by Martin Hauner <ha...@web.de>.
> [APR_ICONV_PATH and Win32]
Hi,
maybe this patch would be a way to go...
It makes iconv_getpath() look at the exe/ddl location first
for the charset libraries on Win32.
If it doesn't find an iconv folder there, it tries to use
APR_ICONV_PATH like before.
This way I can make sure that my program uses "my" iconv
libs if i think this is necessary without manipulation
of APR_ICONV_PATH. Or i can use those in APR_ICONV_PATH
by not providing private iconv libs.
--
Martin
Re: Problems building trunk on Win32
Posted by Branko Čibej <br...@xbc.nu>.
SteveKing wrote:
> Jostein Chr. Andersen wrote:
>
>> On Monday 14 June 2004 20.16, Branko Čibej wrote:
>> ...
>>
>>> What I'm hoping for is that all Subversion clients start using the
>>> same DLLs. Once that happens, you could theoretically fix a "bug" in,
>>> say TortoiseSVN, by upgrading the core Subversion package (libraries +
>>> command-line client, or just the libraries). If we get the packaging
>>> right -- and get other projects to cooperate -- it would make using
>>> Subversion much easier, IMHO.
>>
>>
>>
>> +1 on this one.
>>
>> We could then place all the common DLLs in NT's
>> "%CommonProgramFiles%\Subversion" (and correspondig folder for 9x).
>
>
> I don't like that idea at all. This is an invitation for problems and
> crashs. Ever heard of the "dll hell"? That's exactly what will happen.
> If a program uses (has to use) dlls installed by another app, maybe
> even another version of those dlls than the program was written and
> tested against it _will_ cause problems.
The famous "dll hell" is and always was the result of incorrect
packaging and not paying attention to details. There is no difference
between Unix and Windows in this respect.
> The %CommonProgramFiles% location is intended for software vendors who
> ship whole suites which use all the same libs (e.g. adobe, macromedia,
> ms, ...) but which all programs are tested against those libs.
> MS even has introduced a mechanism in XP (and will be improved in
> Longhorn) which allows to have several dlls with the same name but
> with different versions to reside inside the same folder. Only that
> way it can be assured that a program only uses those dlls it really
> knows.
AFAIK that's true of .NET assemblies, not ordinary DLLs.
> Imagine Subversion 2.0 comes out and the dll's still have the same name.
They won't, by definition. They'll change from libsvn_foo-1.dll to
libsvn_foo-2.dll.
> Now you still have a client which needs the 1.0 dlls, but they're
> overwritten by a newer client which installed the 2.0 version. Can you
> _guarantee_ that the older client still works?
You don't have to, see above.
> I also like to remind you of the problems we already have with the
> iconv library: due to the APR_ICONV_PATH env variable all clients
> already use (have to use) the same lib, even if it was installed by
> another client. And you followed the thread on the TSVN mailing list
> about that too...
AFAIK _that_ particular problem was caused by TSVN not installing the C
runtime where every other app expects it.
> So for me this won't be an option and TSVN will never be part of that.
> I'd rather work on real bugs in my program than having to deal with
> issues arising from incompatible dlls. I will also patch the iconv lib
> for the next release of TSVN so that it won't use the APR_ICONV_PATH
> variable anymore - I don't see any other way to get rid of the
> reported problems.
I do. It's very simple. Don't live in a world of your own. Coordinate
these things with the core project. I'm sure we can define an
installation scheme for the libraries and all clients that will make
them work together.
Really, this is ridiculous. If you're going to fork APR-iconv for TSVN
-- a crazy scheme if I ever saw one, it's one of the most stable parts
of APR -- you may as well fork SVN itself, for all the good it does us.
I proposed to introduce a well-defined interface to the (upcoming)
Subversion core installation for other clients. Our strict API
guarantees allow us to do this. You can either help with this effort in
such a way that it benefits TSVN as well, or you can go your own way.
It's your decision. But if you decide against helping with a common
infrastructure because of some "dll hell" FUD, well, that's tough,
you'll be duplicating work that others could be doing for you.
(Funny, I'd been considering getting "svn status -N" --
svn_client_status, in fact -- to work a bit better, so that TSVN could
have less performance trouble with the overlay icons. Now I wonder if I
should bother.)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by Martin Tomes <li...@tomes.org>.
This is a general comment on the TSVN/Subversion dll debate.
I would like to point out that the Microsoft solution to dll hell in
.NET is that every assembly which uses another assembly has it's own
copy of the dll's. I.e., if TSVN and Subversion programs were .NET
programs (there's a thought!) TSVN would use the Subversion assembly and
Visual Studio .NET would copy the Subversion dll's into the TSVN
assembly. Installing TSVN would mean copying all the required assembly
dll's into the TSVN assembly directory, including the Subversion ones.
Yes, there is a global assembly cache, but it isn't recommended that you
use that.
So even MS now believe the only safe way to do this is for each
application to have it's own copy of a dll which means that it cannot be
broken by another install.
So, I sort of side with Steve King because:
- Every windows application install should be complete in and of
itself. If I install TSVN I cannot be required to have installed
Subversion first.
- TSVN could (and probably should) use the dll's from a Subversion
release, but it has to have it's own copy which it is known works properly.
- The 'common files' thing which some installers use are there for
companies who have a large product range which people buy in bits, so if
one buys product 1 it installs the common bits, then buy product 2 and
they are already there. That company will have built and tested its
products against that common code so it works. If there is a new
version of the common bits the company can make you upgrade all your
applications. I am not convinced that TSVN/Subversion can or even needs
to do all this.
I think that if you wanted common dll's you would have to have common
releases, i.e., there would have to be an install for Windows which
included the Subversion command line and TSVN clients, that way you know
what you are getting. Is it worth it? Probably not.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by SteveKing <st...@gmx.ch>.
Mark Phippard wrote:
>>Sure, repairing or reinstalling TSVN would fix that. But before people
>>do that they come complaining on the mailing list. You see, the
>>apr_iconv libs aren't "vital" for the app. Users won't miss them until
>>they deal with files which have non-ASCII chars in their names.
>
> The way I see it in scenario 1 something is definitely broken, in scenario
> 2 something is only broken in the less likely event that the Subversion
> client is uninstalled.
Maybe unlikely for you. You're forgetting those users who first try
Subversion with the official client, then go searching for a GUI client
(they're Windows users!) and if they find one they like the uninstall
what they don't need anymore.
> But you are trading off having to do this once, when many people will want
> both installed anyway, for having to update multiple clients every time a
> fix is released. Also, I think in the long run it is better for you if it
> is clear to your users where the core Subversion functionality is coming
> from.
Users don't usually care where a library comes from. They just want a
program that works - they don't care how or why.
Imagine Subversion wouldn't install all the libraries it uses but would
require the user to download and install them separately (openssl, neon,
zlib, berkeley db). For a Windows user that's just not acceptable (and
another reason for MS to shoot at open source projects). Ok, you say you
have to do that only once. But you're forgetting that once that's done,
users will have to monitor all project websites for new releases and
then read all the release notes to make sure the new releases are
compatible with each other. Users don't do that - Computer geeks do that.
> Perhaps if your installer found the Subversion DLL's in the path it would
> just skip installing another copy?
That would still mean TSVN would have to use the libs it is not tested
against.
> Since Subversion adds itself to the PATH, and you do not, wouldn't you get
> the Subversion DLL's anyway?
Subversion _has_ to add itself to the path since it is a command line
client and could otherwise not be started from a working copy folder (at
least not without specifying the full path each time). TSVN doesn't (and
shouldn't) do that because it's a GUI and isn't started like the command
line client.
And no, TSVN wouldn't (doesn't) use those dlls: a program always loads a
that dll which resides in the same directory as the application itself -
only if it doesn't find it there Windows then looks in other folders
(including those in PATH) for that dll - the order of those locations is
different for Win98 and NT based OSes. See the MSDN for the exact
searching order.
Stefan
--
God is Real, unless declared Integer.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by Mark Phippard <Ma...@softlanding.com>.
SteveKing <st...@gmx.ch> wrote on 06/15/2004 04:09:54 PM:
> >>scenario 2:
> >>- SVN client get installed, sets APR_ICONV_PATH to \SVN\iconv
> >>- TSVN client gets installed, since APR_ICONV_PATH is already set
> >>doesn't change it
> >>- SVN client gets uninstalled
> >>--> TSVN won't work anymore because the APR_ICONV_PATH points to a
> >>non-existing directory
> >
> > OK, but is this scenario seems better than scenario 1 as it is less
likely
> > to be a problem. Also, wouldn't the repair option on your MSI fix it?
> > This one seems the lesser of two evils.
>
> Sure, repairing or reinstalling TSVN would fix that. But before people
> do that they come complaining on the mailing list. You see, the
> apr_iconv libs aren't "vital" for the app. Users won't miss them until
> they deal with files which have non-ASCII chars in their names.
The way I see it in scenario 1 something is definitely broken, in scenario
2 something is only broken in the less likely event that the Subversion
client is uninstalled.
> > In the case of Subversion itself, because it reinforces the concept
that
> > tools like TSVN and JavaHL and Subclipse are built on top of the
> > Subversion libraries. It is just more clear what is doing what if the
> > instructions make me install Subversion client before I install the
> > others. Also, when Subversion issues something like a security fix
you do
>
> I doubt that people would be happy if I told them:
> To use TSVN you must first go to the website x, download and install y,
> then install TSVN. We're talking about Windows users here: they want to
> doubleclick on an installer and expect that everything works after that.
> (and that's what I most miss on Linux: I can't even tell you how many
> hours I've already spent searching, downloading and building required
> libs for a simple app I needed. And once I thought I had all the libs
> then those libs themselves needed yet another lib I had to download
first.)
But you are trading off having to do this once, when many people will want
both installed anyway, for having to update multiple clients every time a
fix is released. Also, I think in the long run it is better for you if it
is clear to your users where the core Subversion functionality is coming
from.
Perhaps if your installer found the Subversion DLL's in the path it would
just skip installing another copy?
> I will sure use the dll's. And if Subversion makes it a requirement to
> put those dlls in a common place I will do so. But as long as its up to
> the clients where to put them I will put them in the TSVN folder. If you
> then want to use some newer dll's from another client you can copy them
> over manually, but then you're responsible if it doesn't work anymore.
Since Subversion adds itself to the PATH, and you do not, wouldn't you get
the Subversion DLL's anyway?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by SteveKing <st...@gmx.ch>.
Mark Phippard wrote:
>>scenario 2:
>>- SVN client get installed, sets APR_ICONV_PATH to \SVN\iconv
>>- TSVN client gets installed, since APR_ICONV_PATH is already set
>>doesn't change it
>>- SVN client gets uninstalled
>>--> TSVN won't work anymore because the APR_ICONV_PATH points to a
>>non-existing directory
>
> OK, but is this scenario seems better than scenario 1 as it is less likely
> to be a problem. Also, wouldn't the repair option on your MSI fix it?
> This one seems the lesser of two evils.
Sure, repairing or reinstalling TSVN would fix that. But before people
do that they come complaining on the mailing list. You see, the
apr_iconv libs aren't "vital" for the app. Users won't miss them until
they deal with files which have non-ASCII chars in their names.
> In the case of Subversion itself, because it reinforces the concept that
> tools like TSVN and JavaHL and Subclipse are built on top of the
> Subversion libraries. It is just more clear what is doing what if the
> instructions make me install Subversion client before I install the
> others. Also, when Subversion issues something like a security fix you do
I doubt that people would be happy if I told them:
To use TSVN you must first go to the website x, download and install y,
then install TSVN. We're talking about Windows users here: they want to
doubleclick on an installer and expect that everything works after that.
(and that's what I most miss on Linux: I can't even tell you how many
hours I've already spent searching, downloading and building required
libs for a simple app I needed. And once I thought I had all the libs
then those libs themselves needed yet another lib I had to download first.)
> not have to stop your development to build and create a TSVN version of
> the same fix and I the user do not have to install in my case 3 updates
> (svn, tsvn, subclipse) to get 1 security fix.
As I mentioned before, you could also just copy the dll's over to the
other program folders and replace the ones there. But if you do that you
will _know_ what you do and if something breaks you will immediately
know that this could be the reason.
> That one stinks. Is it possible if you were just using SVN DLL's which
> were doing all of the talking to the BDB DLL's that this might not happen?
I don't know. Maybe it would have worked, maybe not. Since I don't know
why those two different C-runtimes interferred and how they interferred
I just don't know if it will work that way. And I don't like to guess
when it comes to a program I release to the public.
> If this were the one and only holdup perhaps SVN could agree to do their
> official release builds with VS .NET instead of Visual Studio 6?
That would work for Subversion and TSVN. But what about the other
clients which don't use VS.NET at all?
>>- Some time ago a subversion client was released which was broken on
>>windows. The apr_iconv library wasn't working. That time only the
>>subversion client was broken, but with a shared library _all_ already
>>installed and working clients would have been broken too.
>
> Is it reasonable to say that now that we are at 1.x stage these problems
> will not happen again in official releases? The client was pre-release in
> those days.
I don't think so. Back then, it too was an official release. And you
don't think that the subversion developers would have released that if
they knew it was broken? It was a mistake which could happen to anyone,
and it could happen again. It could also happen to TSVN - and if that
ever happens I don't want to be responsible for breaking other apps!
>>To sum it up: I'd rather have each client use its own libraries which
>>they are tested against. It's much less risky and doesn't cost much.
>
> When and if Subversion moves to a DLL model, I would like you to at least
> take a look at what they have done and see if it is something you could
> take advantage of.
I will sure use the dll's. And if Subversion makes it a requirement to
put those dlls in a common place I will do so. But as long as its up to
the clients where to put them I will put them in the TSVN folder. If you
then want to use some newer dll's from another client you can copy them
over manually, but then you're responsible if it doesn't work anymore.
Stefan
--
Build a man a fire - keep him warm for a day, set a man on fire - keep
him warm for the rest of his life.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by Mark Phippard <Ma...@softlanding.com>.
Thank you for the thoughtful reply, there is no question that this is a
difficult and complex problem in Windows and with a bad history. I do not
entirely disagree with your viewpoint, particularly where it comes to the
3rd party libraries that do not appear to put the same effort into
packaging and compatability that Subversion itself is trying to do.
> > I hope you will reconsider and try to work more closely with the
> > Subversion team to get this right. I would also like to see
Subversion
>
> You won't believe it, but I'm trying to make TSVN work so that no other
> Subversion client gets affected, that each client can live on its own
> without interfering with others. But there are some issues which prevent
> me from doing it right.
I believe you!
> TSVN uses the msvc71.dll which SVN doesn't have.
> (and no, the msvc72.dll should _not_ be in the windows system dir
> because even MS advises against that)
I agree and it also potentially ups the user requirements for the install.
> scenario 2:
> - SVN client get installed, sets APR_ICONV_PATH to \SVN\iconv
> - TSVN client gets installed, since APR_ICONV_PATH is already set
> doesn't change it
> - SVN client gets uninstalled
> --> TSVN won't work anymore because the APR_ICONV_PATH points to a
> non-existing directory
OK, but is this scenario seems better than scenario 1 as it is less likely
to be a problem. Also, wouldn't the repair option on your MSI fix it?
This one seems the lesser of two evils.
> What I don't get is why do you want all clients to use the same dlls
> shared in one place? What would you gain by doing that? Don't start
> talking about saving disk space - those 5 MB's won't affect you.
In the case of Subversion itself, because it reinforces the concept that
tools like TSVN and JavaHL and Subclipse are built on top of the
Subversion libraries. It is just more clear what is doing what if the
instructions make me install Subversion client before I install the
others. Also, when Subversion issues something like a security fix you do
not have to stop your development to build and create a TSVN version of
the same fix and I the user do not have to install in my case 3 updates
(svn, tsvn, subclipse) to get 1 security fix.
> Just some examples of what already happened so far with dlls:
>
> - When I first started with TSVN I used the precompiled berkeley db
> libraries from the subversion website. I thought it worked very well -
> and why shoudln't it, I used the very same libdb.dll as the command line
> client. But then I got sometimes crashes in TSVN which I couldn't
> explain. Somehow the memory heap got corrupted, and I didn't know why. I
> spent a whole week until I found out that the berkeley db from the
> subversion website was built with VC6 and used msvc60.dll while TSVN
> used msvc70.dll. Once I built my own version of the berkeley db the
> memory heap wasn't corrupted anymore and everything worked great.
> So there weren't even two different versions of the berkeley dll, just
> the same version built with different compilers. Talk about dll hell!
That one stinks. Is it possible if you were just using SVN DLL's which
were doing all of the talking to the BDB DLL's that this might not happen?
If this were the one and only holdup perhaps SVN could agree to do their
official release builds with VS .NET instead of Visual Studio 6?
> - ZoneAlarm (firewall program) installs its own version of the
> ssleay.dll into the windows system folder. This is not a problem for the
> command line client since windows always load the dlls which are in the
> program folder first, but TSVN is a shell extension and gets loaded by
> the windows explorer - and the explorer is in the windows folder. So
> users who have ZoneAlarm and TSVN installed get an error message on each
> login telling that an entry point in the ssleay.dll wasn't found. Not a
> serious problem, but definitely _very_ annoying.
I had a similar problem with Subclipse. It was hard to figure out the
root, then simple to fix.
> - Some time ago a subversion client was released which was broken on
> windows. The apr_iconv library wasn't working. That time only the
> subversion client was broken, but with a shared library _all_ already
> installed and working clients would have been broken too.
Is it reasonable to say that now that we are at 1.x stage these problems
will not happen again in official releases? The client was pre-release in
those days.
> To sum it up: I'd rather have each client use its own libraries which
> they are tested against. It's much less risky and doesn't cost much.
When and if Subversion moves to a DLL model, I would like you to at least
take a look at what they have done and see if it is something you could
take advantage of.
> > and Tortoise get together on build instructions for Windows. The
> > Subversion docs does it one way and the Tortoise docs do it another.
The
> > problem is that Tortoise needs the Subversion files in the proper
places
> > for it to find them, understandable. It is also understandable that
when
>
> I don't see the problem. Where's the difference in the build
instructions?
>
Perhaps it is not a problem any longer. I seem to recall that the
relative locations of some of the folders were in different places. The
SVN instructions have SVN, HTTPD, OpenSSL, ZLIB all as peer folders at the
same level, I thought that you put one or more of these below the SVN
folder.
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by SteveKing <st...@gmx.ch>.
Mark Phippard wrote:
> I disagree with you. I think it would improve the Subversion/Tortoise
> packaging if it was more obvious how they co-exist. Having a set of
> shared Subversion DLL's is the best way to accomplish that. Then when
> these security and other fixes pop-up I can just update Subversion and
> that takes care of everything.
"takes care of everything" - that's what's not possible: the "everything".
> Now that Subversion has 1.0, the API compatability guarantees, along with
> including the major version number in the DLL name, should make DLL Hell
> very unlikely.
I wouldn't say "very unlikely", maybe unlikely, but still possible.
> I hope you will reconsider and try to work more closely with the
> Subversion team to get this right. I would also like to see Subversion
You won't believe it, but I'm trying to make TSVN work so that no other
Subversion client gets affected, that each client can live on its own
without interfering with others. But there are some issues which prevent
me from doing it right.
Example: the infamous APR_ICONV_PATH environement variable
scenario 1:
- SVN client get installed, sets APR_ICONV_PATH to \SVN\iconv
- TSVN client gets installed, sets APR_ICONV_PATH to \TSVN\iconv
--> SVN client doesn't work anymore, because the iconv which comes with
TSVN uses the msvc71.dll which SVN doesn't have.
(and no, the msvc72.dll should _not_ be in the windows system dir
because even MS advises against that)
scenario 2:
- SVN client get installed, sets APR_ICONV_PATH to \SVN\iconv
- TSVN client gets installed, since APR_ICONV_PATH is already set
doesn't change it
- SVN client gets uninstalled
--> TSVN won't work anymore because the APR_ICONV_PATH points to a
non-existing directory
What I don't get is why do you want all clients to use the same dlls
shared in one place? What would you gain by doing that? Don't start
talking about saving disk space - those 5 MB's won't affect you.
But the problems which _can_ arise are serious and real. Sure, with some
luck we would never have such problems. But I've lived long enough
(maybe too long already) to know that luck is something that only others
have.
Just some examples of what already happened so far with dlls:
- When I first started with TSVN I used the precompiled berkeley db
libraries from the subversion website. I thought it worked very well -
and why shoudln't it, I used the very same libdb.dll as the command line
client. But then I got sometimes crashes in TSVN which I couldn't
explain. Somehow the memory heap got corrupted, and I didn't know why. I
spent a whole week until I found out that the berkeley db from the
subversion website was built with VC6 and used msvc60.dll while TSVN
used msvc70.dll. Once I built my own version of the berkeley db the
memory heap wasn't corrupted anymore and everything worked great.
So there weren't even two different versions of the berkeley dll, just
the same version built with different compilers. Talk about dll hell!
- ZoneAlarm (firewall program) installs its own version of the
ssleay.dll into the windows system folder. This is not a problem for the
command line client since windows always load the dlls which are in the
program folder first, but TSVN is a shell extension and gets loaded by
the windows explorer - and the explorer is in the windows folder. So
users who have ZoneAlarm and TSVN installed get an error message on each
login telling that an entry point in the ssleay.dll wasn't found. Not a
serious problem, but definitely _very_ annoying.
- Some time ago a subversion client was released which was broken on
windows. The apr_iconv library wasn't working. That time only the
subversion client was broken, but with a shared library _all_ already
installed and working clients would have been broken too.
- The apr_iconv *.so files don't have a version information built in (no
version resource), so installers can't check if they probably will
overwrite a newer version with an older one.
But it's not only TSVN and Subversion which would run into possible
problems. Even MS has problems with different dll versions. Just browse
the MS knowledge base to find out how many times a bugfix/securityfix or
servicepack (which should _only_ fix bugs and not change the API at all)
broke other apps (e.g. the LSASS fix made some win2k machines boot up,
but then use 100% CPU and render the PC unusable).
What I'm trying to say is that we use one shared library then a newer
client _could_ break older ones (not intentionally). And then there's no
way to make the older client work again, because by reinstalling the
older client it would see (hopefully) that the libs already installed
are newer and _not_ overwrite them, so that client stays broken.
But if every client uses its own libs then a newer client won't have
even the slightes chance to break other clients, so that's definitely
better (so I think). If you then still want the older client to use the
newer libs just copy the lib files manually. If it then still breaks you
will at least have a chance to make it work again by reinstalling it.
Maybe you now think that I'm just paranoid about clients breaking. And
maybe you're right. But I've seen apps break too many times already to
just _hope_ it will work - I want proof!
To sum it up: I'd rather have each client use its own libraries which
they are tested against. It's much less risky and doesn't cost much.
> and Tortoise get together on build instructions for Windows. The
> Subversion docs does it one way and the Tortoise docs do it another. The
> problem is that Tortoise needs the Subversion files in the proper places
> for it to find them, understandable. It is also understandable that when
I don't see the problem. Where's the difference in the build instructions?
Stefan
--
Light travels faster than sound. That's why some people appear bright
until you hear them speak.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by Mark Phippard <Ma...@softlanding.com>.
SteveKing <st...@gmx.ch> wrote on 06/14/2004 05:09:48 PM:
> Jostein Chr. Andersen wrote:
>
> > On Monday 14 June 2004 20.16, Branko Čibej wrote:
> > ...
> >
> >>What I'm hoping for is that all Subversion clients start using the
> >>same DLLs. Once that happens, you could theoretically fix a "bug" in,
> >>say TortoiseSVN, by upgrading the core Subversion package (libraries +
> >>command-line client, or just the libraries). If we get the packaging
> >>right -- and get other projects to cooperate -- it would make using
> >>Subversion much easier, IMHO.
> >
> >
> > +1 on this one.
> >
> > We could then place all the common DLLs in NT's
> > "%CommonProgramFiles%\Subversion" (and correspondig folder for 9x).
>
> I don't like that idea at all. This is an invitation for problems and
> crashs. Ever heard of the "dll hell"? That's exactly what will happen.
> If a program uses (has to use) dlls installed by another app, maybe even
> another version of those dlls than the program was written and tested
> against it _will_ cause problems.
I disagree with you. I think it would improve the Subversion/Tortoise
packaging if it was more obvious how they co-exist. Having a set of
shared Subversion DLL's is the best way to accomplish that. Then when
these security and other fixes pop-up I can just update Subversion and
that takes care of everything.
Now that Subversion has 1.0, the API compatability guarantees, along with
including the major version number in the DLL name, should make DLL Hell
very unlikely.
I hope you will reconsider and try to work more closely with the
Subversion team to get this right. I would also like to see Subversion
and Tortoise get together on build instructions for Windows. The
Subversion docs does it one way and the Tortoise docs do it another. The
problem is that Tortoise needs the Subversion files in the proper places
for it to find them, understandable. It is also understandable that when
you came up with your system, the Subversion build on Windows was not well
documented like it is today. I think it is natural for someone to first
learn how to build Subversion on Windows and them move on to Tortoise. It
would be great if that were a cleaner process by using a common structure
for the files.
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by SteveKing <st...@gmx.ch>.
Jostein Chr. Andersen wrote:
> On Monday 14 June 2004 20.16, Branko Čibej wrote:
> ...
>
>>What I'm hoping for is that all Subversion clients start using the
>>same DLLs. Once that happens, you could theoretically fix a "bug" in,
>>say TortoiseSVN, by upgrading the core Subversion package (libraries +
>>command-line client, or just the libraries). If we get the packaging
>>right -- and get other projects to cooperate -- it would make using
>>Subversion much easier, IMHO.
>
>
> +1 on this one.
>
> We could then place all the common DLLs in NT's
> "%CommonProgramFiles%\Subversion" (and correspondig folder for 9x).
I don't like that idea at all. This is an invitation for problems and
crashs. Ever heard of the "dll hell"? That's exactly what will happen.
If a program uses (has to use) dlls installed by another app, maybe even
another version of those dlls than the program was written and tested
against it _will_ cause problems.
The %CommonProgramFiles% location is intended for software vendors who
ship whole suites which use all the same libs (e.g. adobe, macromedia,
ms, ...) but which all programs are tested against those libs.
MS even has introduced a mechanism in XP (and will be improved in
Longhorn) which allows to have several dlls with the same name but with
different versions to reside inside the same folder. Only that way it
can be assured that a program only uses those dlls it really knows.
Imagine Subversion 2.0 comes out and the dll's still have the same name.
Now you still have a client which needs the 1.0 dlls, but they're
overwritten by a newer client which installed the 2.0 version. Can you
_guarantee_ that the older client still works?
I also like to remind you of the problems we already have with the iconv
library: due to the APR_ICONV_PATH env variable all clients already use
(have to use) the same lib, even if it was installed by another client.
And you followed the thread on the TSVN mailing list about that too...
So for me this won't be an option and TSVN will never be part of that.
I'd rather work on real bugs in my program than having to deal with
issues arising from incompatible dlls. I will also patch the iconv lib
for the next release of TSVN so that it won't use the APR_ICONV_PATH
variable anymore - I don't see any other way to get rid of the reported
problems.
Stefan
--
"The best argument against democracy is a five-minute conversation with
the average voter." - Winston Churchill
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Monday 14 June 2004 20.16, Branko Čibej wrote:
...
> What I'm hoping for is that all Subversion clients start using the
> same DLLs. Once that happens, you could theoretically fix a "bug" in,
> say TortoiseSVN, by upgrading the core Subversion package (libraries +
> command-line client, or just the libraries). If we get the packaging
> right -- and get other projects to cooperate -- it would make using
> Subversion much easier, IMHO.
+1 on this one.
We could then place all the common DLLs in NT's
"%CommonProgramFiles%\Subversion" (and correspondig folder for 9x).
Jostein
--
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>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
>
>
You can do what I did -- take the zlib sources and build your own static
library. The makefile even lets you rename the library on the command line.
>>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.
>
>
We'll obviouisly have to put in some work to get the message translation
support on Windows out of the experimental stage, where it is now.
>>>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.
>
It does, in fact...
>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.
>
>
What I'm hoping for is that all Subversion clients start using the same
DLLs. Once that happens, you could theoretically fix a "bug" in, say
TortoiseSVN, by upgrading the core Subversion package (libraries +
command-line client, or just the libraries). If we get the packaging
right -- and get other projects to cooperate -- it would make using
Subversion much easier, IMHO.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building trunk on Win32
Posted by Mark Phippard <Ma...@softlanding.com>.
Branko Čibej <br...@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
Re: Problems building trunk on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>I am testing building the latest trunk on Win32. I am using the
>instructions found in the file INSTALL, and am using the batch file
>included in ..\build\win32 to run the build.
>
>Problem #1: zlib
>
>There is a zlib version 1.2.1 that has been available for quite a while.
>It is packaged quite different from 1.1.4 and the instructions, as is,
>will not work with 1.2.1. I think the instructions should either be
>updated to use 1.2.1, or should be modified to acknowledge that 1.2.1
>exists but that you should still use 1.1.4.
>
>I was able to use 1.2.1 by copying the file SVN\zlib\lib\zdll.lib
>
That's the wrong library. You should be using the static build, or
building your own.
> to
>SVN\zlib\zlibstat.lib (note the rename). And also by copying the header
>files in SVN\zlib\include to SVN\zlib.
>
>
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.
>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 am not sure where I got this DLL, but perhaps I downloaded too new a
>version? If that is the case the docs should steer you away from that. I
>believe I got this DLL from one of the following:
>
>gettext-runtime-0.13.bin.woe32.zip
>gettext-tools-0.13.bin.woe32.zip
>libiconv-1.9.1.bin.woe32.zip
>
>
Use the libintl from the downloads area on subversion.tigris.org.
>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.
If we changed the build instructions every time someone found a
different way to build, we'd never get anything done. I regularly build
with static zlib 1.2.1, for example, but I see no reason to require that
version -- 1.1.4 is quite good enough.
>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?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org