You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "D.J. Heap" <dj...@gmail.com> on 2005/11/06 18:10:16 UTC
Building on Win32 with VS2005
I've built with the new VS2005, but it required some tweaks and since
I'm probably not going to have time to work on them for a few weeks I
thought I'd post a quick summary in case people start asking about it.
The 1st issue is minor but annoying -- the new compiler spits out a
million warnings due to the deprecation of lots of C functions (can be
suppressed with a define as indicated below):
.\threadproc\win32\proc.c(353) : warning C4996: 'getenv' was declared deprecated
C:\VS2005\VC\include\stdlib.h(483) : see declaration of 'getenv'
Message: 'This function or variable may be unsafe. Consider
using _dupenv_s instead. To disable deprecation, use
_CRT_SECURE_NO_DEPRECATE. See online help for details.'
The 2nd issue is zlib123 -- the new ML doesn't like the assembly
version (tweaking build_zlib.bat or the generator to not use the
assembly version works fine):
inffas32.asm(594) : error A2070: invalid instruction operands
inffas32.asm(596) : error A2070: invalid instruction operands
inffas32.asm(610) : error A2070: invalid instruction operands
inffas32.asm(667) : error A2070: invalid instruction operands
The 3rd issue is linking with neon -- the new VS has 'changed' how
external makefile projects work -- they are no longer automatically
linked even if specified as a project dependency. libneon(D).lib has
to be explicitly specified in the linker inputs for the relevant
projects now.
The 4th issue is that one of the stats tests is failing -- it seems to
be due to a change in how wildcards on the commandline are handled,
but I haven't looked at it very closely yet. It does not seem to be
an actual problem with any code, just the test, at first glance.
Other than those build/test issues, it has worked fine so far.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by "D.J. Heap" <dj...@gmail.com>.
On 11/16/05, D.J. Heap <dj...@gmail.com> wrote:
> On 11/16/05, Brad <br...@insightbb.com> wrote:
> > > > The 4th issue is that one of the stats tests is failing -- it seems
> > > > to
> > > > be due to a change in how wildcards on the commandline are handled,
> > > > but I haven't looked at it very closely yet. It does not seem to be
> > > > an actual problem with any code, just the test, at first glance.
> >
> >
> > > This issue, IMO, is a total bug in VS2005 but MS is saying it is 'by
> > > design'. They have broken wildcard quoting in setargv.obj:
> >
> > Does the same problem happen when you use a single quotation mark,
> > instead of a double?
> >
> > Brad
>
>
> Thanks, that works in both VS2003 and VS2005...anyone know if it works
> in VC6 and Unixy shells? There's 5 or 6 tests that use a double
> quoted * as an argument (usually property values) and so are failing
> when built with VS2005.
Actually, this doesn't work either because they preserve the single
quotes and pass them into the program with the argument. So instead
of getting just * as the argument in svn.exe, we get '*'.
So, it still appears to me that we can't use VS2005's setargv.obj
unless MS fixes it (which appears unlikely at this point).
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by "D.J. Heap" <dj...@gmail.com>.
On 11/16/05, Brad <br...@insightbb.com> wrote:
> > > The 4th issue is that one of the stats tests is failing -- it seems
> > > to
> > > be due to a change in how wildcards on the commandline are handled,
> > > but I haven't looked at it very closely yet. It does not seem to be
> > > an actual problem with any code, just the test, at first glance.
>
>
> > This issue, IMO, is a total bug in VS2005 but MS is saying it is 'by
> > design'. They have broken wildcard quoting in setargv.obj:
>
> Does the same problem happen when you use a single quotation mark,
> instead of a double?
>
> Brad
Thanks, that works in both VS2003 and VS2005...anyone know if it works
in VC6 and Unixy shells? There's 5 or 6 tests that use a double
quoted * as an argument (usually property values) and so are failing
when built with VS2005.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by Brad <br...@insightbb.com>.
> > The 4th issue is that one of the stats tests is failing -- it seems
> > to
> > be due to a change in how wildcards on the commandline are handled,
> > but I haven't looked at it very closely yet. It does not seem to be
> > an actual problem with any code, just the test, at first glance.
> This issue, IMO, is a total bug in VS2005 but MS is saying it is 'by
> design'. They have broken wildcard quoting in setargv.obj:
Does the same problem happen when you use a single quotation mark,
instead of a double?
Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by "D.J. Heap" <dj...@gmail.com>.
>
>
> This issue, IMO, is a total bug in VS2005 but MS is saying it is 'by
> design'. They have broken wildcard quoting in setargv.obj:
>
> http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=1c569ad8-7329-4d95-8588-ad6ed08fe988
>
> If they refuse to fix it, I guess we'll have to expand wildcards
> ourselves on Windows? Any better ideas?
MS has decided that this is by design and not going to change.
However, it appears to me to only be a problem with the tests that try
to use * as a value for properties (such as svn:needs-lock or
svn:ignore). IE, tweaking the tests that do this to use the -F option
rather than passing * directly on the commandline works fine.
Any objections to doing that?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by "D.J. Heap" <dj...@gmail.com>.
I fixed the VS2005 build issues I could in r17306, but there are a
couple left...
> > The 2nd issue is zlib123 -- the new ML doesn't like the assembly
> > version (tweaking build_zlib.bat or the generator to not use the
> > assembly version works fine):
> > inffas32.asm(594) : error A2070: invalid instruction operands
> > inffas32.asm(596) : error A2070: invalid instruction operands
> > inffas32.asm(610) : error A2070: invalid instruction operands
> > inffas32.asm(667) : error A2070: invalid instruction operands
> >
These were due to assumed operand sizes which the new assembler won't
assume anymore -- hopefully the next release of zlib will be fixed
(they are aware of the issue). Some info is available at:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=6306f7dc-2cc2-4591-bd60-5d802178fdfa
> >
> > The 4th issue is that one of the stats tests is failing -- it seems to
> > be due to a change in how wildcards on the commandline are handled,
> > but I haven't looked at it very closely yet. It does not seem to be
> > an actual problem with any code, just the test, at first glance.
This issue, IMO, is a total bug in VS2005 but MS is saying it is 'by
design'. They have broken wildcard quoting in setargv.obj:
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=1c569ad8-7329-4d95-8588-ad6ed08fe988
If they refuse to fix it, I guess we'll have to expand wildcards
ourselves on Windows? Any better ideas?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by Joseph Galbraith <ga...@vandyke.com>.
Branko Čibej wrote:
> Steven Kirk wrote:
>>
>>>> .\threadproc\win32\proc.c(353) : warning C4996: 'getenv' was
>>>> declared deprecated
>>>> C:\VS2005\VC\include\stdlib.h(483) : see declaration of
>>>> 'getenv'
>>>> Message: 'This function or variable may be unsafe. Consider
>>>> using _dupenv_s instead. To disable deprecation, use
>>>> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>>>>
>>>
>>> Aargh! So now #*$@^*&! Microsoft is "deprecating" ISO-C standard
>>> functions, the fscking bastards.
>>>
>> From http://msdn2.microsoft.com/en-us/library/8ef0s5kh
>>
>> It should be noted that in this context, "deprecated" just means that
>> a function's use is not recommended; it does not indicate that the
>> function is scheduled to be removed from the CRT.
> Then they should jolly well pick up a dictionary and learn the language.
Hmmm... dictionary.com:
dep·re·cate Pronunciation Key (dpr-kt)
tr.v. de·pre·cat·ed, de·pre·cat·ing, de·pre·cates
1. To express disapproval of; deplore.
2. To belittle; depreciate.
I believe they have used the word correctly, though maybe not
the way most of us in the computer world think it should be
used.
> And it's about time compilers stopped trying to be smarter than people.
> Granted that your average run-of-the-mill programmer is a moron, it's
> not the compiler's responsibility to educate them.
Compilers _are_ smarter that pretty much everyone but me :-)
But seriously, in this day of buffer overruns, viruses,
worms, spyware, and DRM, I'm not sure that that the new
functions are a completely bad idea... and they did give
you two different ways to turn the warnings off.
Just for example, did you ever think the getenv is unsafe? I
didn't... until I started to think about this particular warning.
I'm still not entirely sure why MS thinks it unsafe, but my
guess is that you can't safely use getenv in a multi-threaded
environment (were some other thread might call putenv and force
the reallocation of the environment block.)
So maybe, just maybe, this isn't an entirely stupid thing... just
a pain in the neck.
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by Branko Čibej <br...@xbc.nu>.
Steven Kirk wrote:
>
>>> .\threadproc\win32\proc.c(353) : warning C4996: 'getenv' was
>>> declared deprecated
>>> C:\VS2005\VC\include\stdlib.h(483) : see declaration of
>>> 'getenv'
>>> Message: 'This function or variable may be unsafe. Consider
>>> using _dupenv_s instead. To disable deprecation, use
>>> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>>>
>>
>> Aargh! So now #*$@^*&! Microsoft is "deprecating" ISO-C standard
>> functions, the fscking bastards.
>>
> From http://msdn2.microsoft.com/en-us/library/8ef0s5kh
>
> It should be noted that in this context, "deprecated" just means that
> a function's use is not recommended; it does not indicate that the
> function is scheduled to be removed from the CRT.
Then they should jolly well pick up a dictionary and learn the language.
And it's about time compilers stopped trying to be smarter than people.
Granted that your average run-of-the-mill programmer is a moron, it's
not the compiler's responsibility to educate them.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by Steven Kirk <st...@status-scientific.com>.
>> .\threadproc\win32\proc.c(353) : warning C4996: 'getenv' was declared
>> deprecated
>> C:\VS2005\VC\include\stdlib.h(483) : see declaration of 'getenv'
>> Message: 'This function or variable may be unsafe. Consider
>> using _dupenv_s instead. To disable deprecation, use
>> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>>
>
> Aargh! So now #*$@^*&! Microsoft is "deprecating" ISO-C standard
> functions, the fscking bastards.
>
From http://msdn2.microsoft.com/en-us/library/8ef0s5kh
It should be noted that in this context, "deprecated" just means that a
function's use is not recommended; it does not indicate that the
function is scheduled to be removed from the CRT.
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 05/11/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building on Win32 with VS2005
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
> I've built with the new VS2005, but it required some tweaks and since
> I'm probably not going to have time to work on them for a few weeks I
> thought I'd post a quick summary in case people start asking about it.
>
> The 1st issue is minor but annoying -- the new compiler spits out a
> million warnings due to the deprecation of lots of C functions (can be
> suppressed with a define as indicated below):
>
> .\threadproc\win32\proc.c(353) : warning C4996: 'getenv' was declared deprecated
> C:\VS2005\VC\include\stdlib.h(483) : see declaration of 'getenv'
> Message: 'This function or variable may be unsafe. Consider
> using _dupenv_s instead. To disable deprecation, use
> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>
Aargh! So now #*$@^*&! Microsoft is "deprecating" ISO-C standard
functions, the fscking bastards.
> The 2nd issue is zlib123 -- the new ML doesn't like the assembly
> version (tweaking build_zlib.bat or the generator to not use the
> assembly version works fine):
> inffas32.asm(594) : error A2070: invalid instruction operands
> inffas32.asm(596) : error A2070: invalid instruction operands
> inffas32.asm(610) : error A2070: invalid instruction operands
> inffas32.asm(667) : error A2070: invalid instruction operands
>
There's not much to be done here, except figuring out what's wrong with
the syntax and posting a patch to the zlib folks.
> The 3rd issue is linking with neon -- the new VS has 'changed' how
> external makefile projects work -- they are no longer automatically
> linked even if specified as a project dependency. libneon(D).lib has
> to be explicitly specified in the linker inputs for the relevant
> projects now.
>
>
> The 4th issue is that one of the stats tests is failing -- it seems to
> be due to a change in how wildcards on the commandline are handled,
> but I haven't looked at it very closely yet. It does not seem to be
> an actual problem with any code, just the test, at first glance.
>
> Other than those build/test issues, it has worked fine so far.
>
O.K. So it seems we'll be able to move to a recent version of VS.NET for
svn-2.0.x. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org