You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Andreas Richter <ar...@oszine.de> on 2005/08/17 09:30:43 UTC
MinGW libraries
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
have anybody compiled the subversion libraries with MinGW? I develop at
the moment a Qt based subversion client with MinGW. But i can't use the
provided svn win32 development libraries because these are compiled with
MSVCC.
Are there a similar zip file such as the svn-win32-1.2.1_dev.zip but for
MinGW compiler?
Or must i compile everything from scratch with my MinGW?
tia
- --
Greetings / Gruss
Andreas Richter http://www.oszine.de
GPG-KeyID 0x7BA12DD9
Fingerprint D2E9 202B F4F0 EB16 25DE 5FF7 0CF2 3C57 7BA1 2DD9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFDAwPDDPI8V3uhLdkRArcRAJ0emKet2/ndS+HfI1PnFYvrt1OfVQCYtt5/
m0xTmgLCiPDZVwLsnyjeRg==
=lyQ5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Andreas Richter <ar...@oszine.de>.
Am Mittwoch, 17. August 2005 23:15 schrieb Branko Čibej:
> Andreas Richter wrote:
> >As i read in [1] SteveKing already make a patch to build subversion as
> > dll. What about that patch?
>
> If you follow that discussion, you'll find that I already answered that
> question. I don't want a single svn.dll on Windows.
No. I haven't read all. And rigth: that make no sense to provide a single
svn.dll.
--
Greetings / Gruss
Andreas Richter http://www.oszine.de
GPG-KeyID 0x7BA12DD9
Fingerprint D2E9 202B F4F0 EB16 25DE 5FF7 0CF2 3C57 7BA1 2DD9
Re: MinGW libraries
Posted by Branko Čibej <br...@xbc.nu>.
Andreas Richter wrote:
>As i read in [1] SteveKing already make a patch to build subversion as dll.
>What about that patch?
>
>
If you follow that discussion, you'll find that I already answered that
question. I don't want a single svn.dll on Windows.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Toby Johnson <to...@etjohnson.us>.
Andreas Richter wrote:
>I have no VC6 or similiar. So i can't check this out.
>
>
Not sure if you're aware, but Microsoft has released the same C/C++
compiler that ships with VS.Net 2003 as a free standalone download
called the Visual C++ Toolkit:
<http://msdn.microsoft.com/visualc/vctoolkit2003/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Andreas Richter <ar...@oszine.de>.
Am Mittwoch, 17. August 2005 14:59 schrieb Erik Huelsmann:
> Currently we have a configure script which runs on many (all?) unix
> flavors, but has not been tested with any unix emulators on Windows.
> On windows we use gen_win.py from the root of the source tree.
> Currently it can't generate makefiles (because no-one ever wanted to
> compile with anything but MSVC.)
I think to compile subversion with MinGW is a nightmare. I have begin to try
compile arp. But without success :(
So i hope we can build subversion client libs as dlls.
> If you want to know what to do in order to enable creation of DLLs,
> you can start by reading
> http://svn.haxx.se/dev/archive-2005-08/0319.shtml and
> http://svn.haxx.se/dev/archive-2003-10/0617.shtml . There's probably
> more in the archives. There might even be an issue in the issue
> database.
As i read in [1] SteveKing already make a patch to build subversion as dll.
What about that patch?
I have no VC6 or similiar. So i can't check this out.
> Also, I'm cc-ing brane on this. He wants this to be done a long time
> already (but didn't have the time to do it). I hope brane and I can
> help you create a patch which will enable DLLs for Win32.
Please Brane, lets compile subversion as dll ;)
> I'm afraid you won't be able to compile svn with mingw for now. You
> still won't after we can generate DLLs, but we will be able to provide
> you with DLLs to link against...
Right. No way at the moment to compile subversion with MinGW :(
[1] http://www.contactor.se/~dast/svn/archive-2003-03/1457.shtml
--
Greetings / Gruss
Andreas Richter http://www.oszine.de
GPG-KeyID 0x7BA12DD9
Fingerprint D2E9 202B F4F0 EB16 25DE 5FF7 0CF2 3C57 7BA1 2DD9
Re: MinGW libraries
Posted by Andreas Richter <ar...@oszine.de>.
Am Mittwoch, 17. August 2005 21:53 schrieb Branko Čibej:
> Here's how I would like to do it:
>
> * First, teach the gen_win.py to change the names of all the
> libsvn_* static libraries. Currently the static libarries are
> called "libsvn_foo-m.lib", wher "m" is the svn major version (this
> is the same as on Unix). I'd change that to "svn_foo-m.lib". These
> new static lib projects should not have any library dependencies.
>
> * Next, make generator create an additional project for each
> libsvn_* library that creates libsvn_foo-m.n.{dll,lib,exp}, where
> "m" is the major and "n" the minor version number -- these are the
> DLL, the import library and the exported symbol library. The idea
> is to simply take the svn_foo-m.lib static library and link it
> into a DLL. These projects would depend on the static library, the
> external libraries such as APR, and other Subversion DLLs. This
> step requires a DEF file generator, which I believe has been 90%
> done for ages.
>
> * The unit test programs should link with static libraries, not the
> DLLs, because they sometimes use private functions from the
> library. We shouldn't export those from the DLLs, except in the
> IIRC one case where we're cheating already.
>
> * The projects for the command-line programs should come in two
> flavours, statically and dynamically linked, so that people can
> use the statically-linked versions for upgrades. Maybe it would be
> enough to do this for svnadmin only, in which case I'd make it
> statically linked to APR and BDB, too... well, we'll see.
>
> The reason I'd like to rename the static libraries is to make SVN
> consistent with APR on Windows (where you have the static
> apr(_util)-m.lib and shared libapr(_util)-m.dll), and I think it makes
> sense to encode both the major and minor version numbers in the DLLs,
> because we need both to define the available set of APIs.
This sounds good and i'm happy that you want help me and all other developers
who can than link against these dll :)
> You'd have to fix the APR configury and teach it about MinGW/MSys first.
> That's been on the APR wishlist for a long time, but I don't thing it's
> simple to do.
That's the problem. It's not simple and not a "5-minute-job"...
--
Greetings / Gruss
Andreas Richter http://www.oszine.de
GPG-KeyID 0x7BA12DD9
Fingerprint D2E9 202B F4F0 EB16 25DE 5FF7 0CF2 3C57 7BA1 2DD9
Re: MinGW libraries
Posted by Max Bowsher <ma...@ukf.net>.
Branko Čibej wrote:
> Unlike Unix, Windows doesn't have --rpath or LD_LIBRARY_PATH, and once a
> DLL is loaded by one application, usually other applications that need
> the same DLL will try to use it. ("Usually" because there are edge
> cases).
Do you have more details on these edge cases?
> Encoding the exact API version in the DLL name avoids
> compatibility problems.
>
> Notice that we haven't had a single instance of the Windows SVN binary
> picking up the wrong BDB shared lib, whilst these problems have been
> relatively common on Unix. BDB's DLL naming convention automagically
> avoids this issue.
That's not quite a fair comparison.
BDB encodes major and minor versions in the DLL name, because changed minor
versions aren't supposed to be binary compatible replacements. On the other
hand, micro version increments, are compatible, so the micro version isn't
in the DLL name.
Subversion minor version increments are supposed to be binary compatible, so
by the same logic, the DLL name doesn't include the minor number, only the
major.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> On Aug 17, 2005, at 10:34 PM, Branko Čibej wrote:
>
>>> You can't prevent someone overwriting the dlls, but I don't think
>>> you need to worry about that scenario. If the official Sibversion
>>> installer installs C:\Program files\Subversion\bin\libsvn-1.dll
>>> then the end users heads be on it if they attempt to overwrite that
>>> with an earlier OR later version without using the corresponding
>>> installer.
>>
>>
>> A newer version should never be a problem. An older one could be.
>
> I don't understand how this problem is unique to Windows...?
If you quote this out of context, then of course it's not. :)
Unlike Unix, Windows doesn't have --rpath or LD_LIBRARY_PATH, and once a
DLL is loaded by one application, usually other applications that need
the same DLL will try to use it. ("Usually" because there are edge
cases). Encoding the exact API version in the DLL name avoids
compatibility problems.
Notice that we haven't had a single instance of the Windows SVN binary
picking up the wrong BDB shared lib, whilst these problems have been
relatively common on Unix. BDB's DLL naming convention automagically
avoids this issue.
(And as an interesting anecdote, when I originally added the runtime BDB
version checking to our code, I actually had to rename the BDB DLL in
order to test it on Windows. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 17, 2005, at 10:34 PM, Branko Čibej wrote:
>
>
>> You can't prevent someone overwriting the dlls, but I don't think
>> you need to worry about that scenario. If the official Sibversion
>> installer installs C:\Program files\Subversion\bin\libsvn-1.dll
>> then the end users heads be on it if they attempt to overwrite
>> that with an earlier OR later version without using the
>> corresponding installer.
>>
>
> A newer version should never be a problem. An older one could be.
>
>
I don't understand how this problem is unique to Windows...?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Branko Čibej <br...@xbc.nu>.
Walter Nicholls wrote:
>
>> There's a dilemma here, known as "Windows DLL hell". Since we have no
>> control over installations, we can't prevent somebody from
>> _downgrading_ the installed DLLs. If the DLL names in svn-1.x are the
>> same as in svn-1.x+1, the newer stuff will break.
>
> No control over installations? I'm sure some overwhelming percentage
> of Windows users use the official Subversion MSI packages.
That's funny, given that there _are_ no official Subversion MSI packages. :)
> You can't prevent someone overwriting the dlls, but I don't think you
> need to worry about that scenario. If the official Sibversion
> installer installs C:\Program files\Subversion\bin\libsvn-1.dll then
> the end users heads be on it if they attempt to overwrite that with an
> earlier OR later version without using the corresponding installer.
A newer version should never be a problem. An older one could be.
> If you were to install the DLLs in c:\windows\system32 then DLL hell
> would be a problem. So don't do that!
Of course not. Perish the thought!
> I don't even think you need to include the major version number in the
> file name. Just looking in my C:\program files\Subversion\bin\
> directory, there is:
> intl.dll, intl3_svn.dll, libapr.dll, libapriconv.dll,
> libaprutil.dll ... svn.exe, svnadmin.exe, svndumpfilter.exe ...
See? You've already got mixed versions, "intl.dll" shouldn't be there. :)
And yes, we do need to include the major version in the name, at least.
That's project policy. In fact, it's APR's project policy too, and I
think it's a bug that APR's build doesn't put those names in the APR
DLLS....
> In fact the only files in here with any kind of version numbers in the
> filename are the BDB ones (libdb42.dll, libdb43.dll)
Indeed. And a good thing, too; because of that, it's impossible to load
the wrong BDB libary at runtime.
> I don't have any DLL hell problems with libapr.dll. And why isn't that
> "svn1.exe" or "svn-1.2.1.exe" then? I have a couple of scripts that
> parse svn.exe output, they could equally break if I downgraded say to
> svn 1.1
Executables are a different beast. The thing about DLLs is that, if
program A loads DLL D, and you then run program B that depends on a
(possibly quite different) DLL that also happens to be called D, B will
blindly try to link to the already-loaded D. Bang!
(O.K., this is not strictly true on newer versions of Windows, but it's
true for 99% of the installed base.)
> I can run two versions of Subversion by installing one in c:\program
> files\svn1.1 and another in c:\program files\svn1.2\ or the like
Exactly. And you can't do this safely with DLLs.
> The issue of MSVC6 vs VS.NET (vs Borland C++ builder vs...) is
> possibly a good one - although I would have expected that could be
> solved by defining the calling conventions properly. That may be more
> work thatn any wants to do though.
It's not about calling conventions, the problem is the runtime those
DLLs link to -- specifically, the format of the malloc heap. They're
incompatible.
> Perhaps the biggest problem is that with open-source products like
> this, people can create their own custom builds and break something
> that way.
So? We _want_ to support that, and I don't see it as being a problem --
therefore we'll put version numbers and runtome IDs in the DLL names,
thus avoiding possible clashes.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Walter Nicholls <wa...@cornerstone.co.nz>.
> There's a dilemma here, known as "Windows DLL hell". Since we have no
> control over installations, we can't prevent somebody from
> _downgrading_ the installed DLLs. If the DLL names in svn-1.x are the
> same as in svn-1.x+1, the newer stuff will break.
No control over installations? I'm sure some overwhelming percentage of
Windows users use the official Subversion MSI packages.
You can't prevent someone overwriting the dlls, but I don't think you
need to worry about that scenario. If the official Sibversion installer
installs C:\Program files\Subversion\bin\libsvn-1.dll then the end
users heads be on it if they attempt to overwrite that with an earlier
OR later version without using the corresponding installer.
If you were to install the DLLs in c:\windows\system32 then DLL hell
would be a problem. So don't do that!
I don't even think you need to include the major version number in the
file name. Just looking in my C:\program files\Subversion\bin\
directory, there is:
intl.dll, intl3_svn.dll, libapr.dll, libapriconv.dll,
libaprutil.dll ... svn.exe, svnadmin.exe, svndumpfilter.exe ...
In fact the only files in here with any kind of version numbers in the
filename are the BDB ones (libdb42.dll, libdb43.dll)
I don't have any DLL hell problems with libapr.dll. And why isn't that
"svn1.exe" or "svn-1.2.1.exe" then? I have a couple of scripts that
parse svn.exe output, they could equally break if I downgraded say to
svn 1.1
I can run two versions of Subversion by installing one in c:\program
files\svn1.1 and another in c:\program files\svn1.2\ or the like
The issue of MSVC6 vs VS.NET (vs Borland C++ builder vs...) is possibly
a good one - although I would have expected that could be solved by
defining the calling conventions properly. That may be more work thatn
any wants to do though.
Perhaps the biggest problem is that with open-source products like this,
people can create their own custom builds and break something that way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Branko Čibej <br...@xbc.nu>.
Max Bowsher wrote:
> Branko Čibej wrote:
>
>> I think it makes
>> sense to encode both the major and minor version numbers in the DLLs,
>> because we need both to define the available set of APIs.
>
>
> If you want the DLLs to be usable in the ways described by our
> compatibility rules, you *must* encode only the major number in the name.
> Otherwise, something built against 1.1 won't work with 1.2, which our
> compat rules say it should.
There's a dilemma here, known as "Windows DLL hell". Since we have no
control over installations, we can't prevent somebody from _downgrading_
the installed DLLs. If the DLL names in svn-1.x are the same as in
svn-1.x+1, the newer stuff will break.
Come to think of it, I think we should even encode the runtime version
in the DLL name, so that a program compiled with VS.NET won't pick up
DLLs created with MSVC6 by mistake.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Max Bowsher <ma...@ukf.net>.
Branko Čibej wrote:
> I think it makes
> sense to encode both the major and minor version numbers in the DLLs,
> because we need both to define the available set of APIs.
If you want the DLLs to be usable in the ways described by our compatibility
rules, you *must* encode only the major number in the name.
Otherwise, something built against 1.1 won't work with 1.2, which our compat
rules say it should.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Branko Čibej <br...@xbc.nu>.
Erik Huelsmann wrote:
>>>- Compile everything yourself (which probably implies creating a
>>>Makefile based system which is Win32 compliant)
>>>
>>>
>>I thinks the Makefile based system is not such a problem. MSys should be
>>ok for that job.
>>
>>
>
>Currently we have a configure script which runs on many (all?) unix
>flavors, but has not been tested with any unix emulators on Windows.
>
>
It's supposed to work with Cygwin... not that that's much help.
>On windows we use gen_win.py from the root of the source tree.
>Currently it can't generate makefiles (because no-one ever wanted to
>compile with anything but MSVC.)
>
>
>
>>>- Enhance the build system so that we can generate DLLs so you can
>>>link against the dlls. This would help users of other languages too.
>>>(/me hopes this is a viable solution)
>>>
>>>
>>Thats a good idea. But! I have no idea how your build system works. Can
>>anybod give me some hints?
>>
>>
>If you want to know what to do in order to enable creation of DLLs,
>you can start by reading
>http://svn.haxx.se/dev/archive-2005-08/0319.shtml and
>http://svn.haxx.se/dev/archive-2003-10/0617.shtml . There's probably
>more in the archives. There might even be an issue in the issue
>database.
>
>Also, I'm cc-ing brane on this. He wants this to be done a long time
>already (but didn't have the time to do it). I hope brane and I can
>help you create a patch which will enable DLLs for Win32.
>
>
Here's how I would like to do it:
* First, teach the gen_win.py to change the names of all the
libsvn_* static libraries. Currently the static libarries are
called "libsvn_foo-m.lib", wher "m" is the svn major version (this
is the same as on Unix). I'd change that to "svn_foo-m.lib". These
new static lib projects should not have any library dependencies.
* Next, make generator create an additional project for each
libsvn_* library that creates libsvn_foo-m.n.{dll,lib,exp}, where
"m" is the major and "n" the minor version number -- these are the
DLL, the import library and the exported symbol library. The idea
is to simply take the svn_foo-m.lib static library and link it
into a DLL. These projects would depend on the static library, the
external libraries such as APR, and other Subversion DLLs. This
step requires a DEF file generator, which I believe has been 90%
done for ages.
* The unit test programs should link with static libraries, not the
DLLs, because they sometimes use private functions from the
library. We shouldn't export those from the DLLs, except in the
IIRC one case where we're cheating already.
* The projects for the command-line programs should come in two
flavours, statically and dynamically linked, so that people can
use the statically-linked versions for upgrades. Maybe it would be
enough to do this for svnadmin only, in which case I'd make it
statically linked to APR and BDB, too... well, we'll see.
The reason I'd like to rename the static libraries is to make SVN
consistent with APR on Windows (where you have the static
apr(_util)-m.lib and shared libapr(_util)-m.dll), and I think it makes
sense to encode both the major and minor version numbers in the DLLs,
because we need both to define the available set of APIs.
>>What i have to do so far:
>>I installed MSys + MinGW so i can use configure script in subversion
>>source. But it stops with
>>
>>/home/arichter/subversion-1.2.1/apr/configure:Error: decision on
>>anonymous shared memory allocation method failed
>>configure failed for apr
>>
>>No idea at the moment how i can fix this issue.
>>
>>
You'd have to fix the APR configury and teach it about MinGW/MSys first.
That's been on the APR wishlist for a long time, but I don't thing it's
simple to do.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Erik Huelsmann <eh...@gmail.com>.
> > - Compile everything yourself (which probably implies creating a
> > Makefile based system which is Win32 compliant)
>
> I thinks the Makefile based system is not such a problem. MSys should be
> ok for that job.
Currently we have a configure script which runs on many (all?) unix
flavors, but has not been tested with any unix emulators on Windows.
On windows we use gen_win.py from the root of the source tree.
Currently it can't generate makefiles (because no-one ever wanted to
compile with anything but MSVC.)
> > - Enhance the build system so that we can generate DLLs so you can
> > link against the dlls. This would help users of other languages too.
> > (/me hopes this is a viable solution)
>
> Thats a good idea. But! I have no idea how your build system works. Can
> anybod give me some hints?
If you want to know what to do in order to enable creation of DLLs,
you can start by reading
http://svn.haxx.se/dev/archive-2005-08/0319.shtml and
http://svn.haxx.se/dev/archive-2003-10/0617.shtml . There's probably
more in the archives. There might even be an issue in the issue
database.
Also, I'm cc-ing brane on this. He wants this to be done a long time
already (but didn't have the time to do it). I hope brane and I can
help you create a patch which will enable DLLs for Win32.
> What i have to do so far:
> I installed MSys + MinGW so i can use configure script in subversion
> source. But it stops with
>
> /home/arichter/subversion-1.2.1/apr/configure:Error: decision on
> anonymous shared memory allocation method failed
> configure failed for apr
>
> No idea at the moment how i can fix this issue.
I'm afraid you won't be able to compile svn with mingw for now. You
still won't after we can generate DLLs, but we will be able to provide
you with DLLs to link against...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Andreas Richter <ar...@oszine.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> - Compile everything yourself (which probably implies creating a
> Makefile based system which is Win32 compliant)
I thinks the Makefile based system is not such a problem. MSys should be
ok for that job.
> - Enhance the build system so that we can generate DLLs so you can
> link against the dlls. This would help users of other languages too.
> (/me hopes this is a viable solution)
Thats a good idea. But! I have no idea how your build system works. Can
anybod give me some hints?
What i have to do so far:
I installed MSys + MinGW so i can use configure script in subversion
source. But it stops with
/home/arichter/subversion-1.2.1/apr/configure:Error: decision on
anonymous shared memory allocation method failed
configure failed for apr
No idea at the moment how i can fix this issue.
- --
Greetings / Gruss
Andreas Richter http://www.oszine.de
GPG-KeyID 0x7BA12DD9
Fingerprint D2E9 202B F4F0 EB16 25DE 5FF7 0CF2 3C57 7BA1 2DD9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDAyfiDPI8V3uhLdkRApxzAKDPLv0WWJK1VhpBrHJvX2KY2rEhnwCaAuCy
g9POnwsaLO3m9MAHILyc+Oc=
=iHkS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MinGW libraries
Posted by Erik Huelsmann <eh...@gmail.com>.
> Has anybody compiled the subversion libraries with MinGW? I develop at
> the moment a Qt based subversion client with MinGW. But i can't use the
> provided svn win32 development libraries because these are compiled with
> MSVCC.
> Are there a similar zip file such as the svn-win32-1.2.1_dev.zip but for
> MinGW compiler?
No, no other libraries are provided than the MSVCC ones (because we
create modules for Apache which is built with MSVCC too).
> Or must i compile everything from scratch with my MinGW?
Well, there are 2 things you can do:
- Compile everything yourself (which probably implies creating a
Makefile based system which is Win32 compliant)
- Enhance the build system so that we can generate DLLs so you can
link against the dlls. This would help users of other languages too.
(/me hopes this is a viable solution)
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org