|
Notes |
|
|
(0023278)
|
|
beschulz
|
|
2010-11-15 18:32
|
|
|
Attatched a file with compile errors from my try to run gccxml. I don't know if this is of any use to anyone. |
|
|
|
(0023282)
|
|
Brad King
|
|
2010-11-16 08:39
|
|
Thanks for working on this. I've integrated your changes locally to test. I don't know when I'll have time to try it in detail though.
About the vs10 registry location: do you have the express edition or the professional edition? My professional edition installation does have the expected registry value. Watch out for the Wow6432Node in the registry when viewing with regedit. 32-bit application registry entries lie under it in that view.
Generating those patch files is more of an art than a straightforward process. I usually copy the whole header directory into a local work directory and put it under version control. Then I hack gxConfiguration.cxx to use that instead of the real installation. That way all the errors point at files I can actually edit. Once finished I can use the version control tool to generate the patch. Take a look at how some of the errors were fixed in the patch files for the other versions for more hints. Many of them are probably the same. |
|
|
|
(0023296)
|
|
beschulz
|
|
2010-11-16 12:41
|
|
I have Visual Studio 2010 Professional. And the Wow6432Node Node did the trick. Is this blended in transparently when querying for HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0\\Setup\\VC;ProductDir?(I'll check it of if i've some time on my hands) If so, we should be able to proccees with the normal numbering scheme.
In regards to the overall detection scheme: for my taste it appears to be a little - no offense - messy. It looks like grown from version to version and if nowbody would have guessed that at some point there would be more than three versions to support. I'd really like to refactor that but i'm hesitating because of the involved testing. I do not want to install ten different versions of Visual Studio.
I will take another round at generating the patches. The workflow you described sounds like it could work. But how do you know that you've catched everything. Do you have a "include-all" header and work your way throu that?
regards
-- Benjamin |
|
|
|
(0023299)
|
|
Brad King
|
|
2010-11-16 12:55
|
|
> Wow6432Node ... Is this blended in transparently
Yes.
> overall detection scheme ... messy ... grown from version to version
I agree, and yes it has just grown. For each new version we just add the minimal change. We didn't know ahead of time that so many versions would be consistent with their predecessors. For testing, I have all the versions installed (except 7.0 which won't install on a 64-bit box), but not the express versions.
> Do you have a "include-all" header
Yes. See attached file vcTest.cxx which I used for the VS9 patches. |
|
|
|
(0023365)
|
|
beschulz
|
|
2010-11-17 18:34
|
|
I've attatched the patch-files i've generated. Hope they work - at least on my machine they work. all headers (except the ones from below) run clean through gcc-xml:
#include <crtassem.h> //not found
#include <xmath.h> //not found
#include <xcomplex> //internal header ???
#include <functional> //whoohoo, what's going on here, thats way too much for me
What i find noteworthy is, that allmost all of my changes has to do with double references (&&), i guess that might have something to do with c++0x. I remember reading something somewhere about lacking support in gcc prior to 4.2.
I also added "-D_HAS_CPP0X=0 " to gxConfiguration.cxx.
that was even less fun than i thoght it would be ;o)
regards
-- Benjamin Schulz |
|
|
|
(0023395)
|
|
Brad King
|
|
2010-11-18 14:47
|
|
Thanks for the leg work on this. I've finished <functional> and done some transformation and cleanup of the patches.
Here is VS 10 support:
/cvsroot/GCC_XML/gccxml/GCC_XML/GXFront/gxConfiguration.cxx,v <-- GCC_XML/GXFront/gxConfiguration.cxx
new revision: 1.72; previous revision: 1.71
/cvsroot/GCC_XML/gccxml/GCC_XML/GXFront/gxConfiguration.h,v <-- GCC_XML/GXFront/gxConfiguration.h
new revision: 1.19; previous revision: 1.18
/cvsroot/GCC_XML/gccxml/GCC_XML/VcInstall/CMakeLists.txt,v <-- GCC_XML/VcInstall/CMakeLists.txt
new revision: 1.15; previous revision: 1.14
/cvsroot/GCC_XML/gccxml/GCC_XML/VcInstall/vc10Include.patch,v <-- GCC_XML/VcInstall/vc10Include.patch
initial revision: 1.1
/cvsroot/GCC_XML/gccxml/GCC_XML/VcInstall/vc10PlatformSDK.patch,v <-- GCC_XML/VcInstall/vc10PlatformSDK.patch
initial revision: 1.1
/cvsroot/GCC_XML/gccxml/GCC_XML/VcInstall/vcInstall.cxx,v <-- GCC_XML/VcInstall/vcInstall.cxx
new revision: 1.39; previous revision: 1.38 |
|
|
|
(0025230)
|
|
Martin Bergtholdt
|
|
2011-02-03 06:04
|
|
|
I'm trying to compile Python Wrappers on Windows-7 x64 for ITK but do not succeed. I use the current GIT-Repo of ITK and CVS of CableSwig together with Swig 2.0.1 for Visual Studio 2010. When I did not succeed with x64 builds I reverted to a x86 build, but I get the same erros. They seem to be related to Microsoft's implementation of the stl. I attached the error log for a particular subproject. |
|
|
|
(0025232)
|
|
Brad King
|
|
2011-02-03 09:40
|
|
0011463:0025230: I can reproduce the same error just by running:
$ cat test.cxx
#include <vector>
void f(std::vector<void*>& va, void* a)
{
va.push_back(a);
}
$ gccxml --gccxml-compiler msvc10 test.cxx
(same error as you reported) |
|
|
|
(0025233)
|
|
Brad King
|
|
2011-02-03 09:44
|
|
The problem is that gccxml's patch for <xmemory> (used by <vector>) does this:
#if 0 /* Disabled for gccxml */
// TEMPLATE FUNCTIONS _Cons_val AND _Dest_val
template<class _Alloc,
class _Ty1,
class _Ty2>
void _Cons_val(_Alloc& _Alval, _Ty1 *_Pdest, _Ty2&& _Src)
{ // construct using allocator
_Alval.construct(_Pdest, _STD forward<_Ty2>(_Src));
}
#endif /* Disabled for gccxml */
to avoid use of C++0x rvalue references which are not supported by gccxml's GCC 4.2 parser. We will need an additional workaround to support MS STL code that depends on this method. |
|
|
|
(0025234)
|
|
Brad King
|
|
2011-02-03 10:06
|
|
This patch fixes the above example:
Fix VS10 headers to avoid use of C++0x in function bodies (0011463)
/cvsroot/GCC_XML/gccxml/GCC_XML/VcInstall/vc10Include.patch,v <-- GCC_XML/VcInstall/vc10Include.patch
new revision: 1.2; previous revision: 1.1
I won't be surprised if more instances of cases like this show up later in your build though. Please post again if so. |
|
|
|
(0025278)
|
|
Martin Bergtholdt
|
2011-02-04 08:30
(edited on: 2011-02-04 10:34) |
|
With this patch (using current CVS) half of the errors have been gone, I still get the output from error2.txt. I can further reduce the number of errors when putting a:
#define __noop(...)
in to xmemory. And replacing lines 2506ff from xutility with:
#if 0 /* Disabled for gccxml */
// TEMPLATE FUNCTION move
template<class _InIt,
class _OutIt> inline
_OutIt _Move(_InIt _First, _InIt _Last,
_OutIt _Dest, _Nonscalar_ptr_iterator_tag)
{ // move [_First, _Last) to [_Dest, ...), arbitrary iterators
for (; _First != _Last; ++_Dest, ++_First)
*_Dest = _STD move(*_First);
return (_Dest);
}
#else
template<class _InIt,
class _OutIt> inline
_OutIt _Move(_InIt _First, _InIt _Last,
_OutIt _Dest, _Nonscalar_ptr_iterator_tag);
#endif /* Disabled for gccxml */
Just one error remains for the is_scalar template (see end of error2.txt):
error: 'value' is not a member of 'std::tr1::is_scalar<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >'
This seems to be the only big issue remaining from building Wrappers for ITK. The only other thing I get is this (several times):
82>D:\Programming\CC\build\vs10x32_shared_release\itk\Wrapping\WrapITK\Typedefs\ITKCommonBase.i(200): warning 350: operator new ignored
82>D:\Programming\CC\build\vs10x32_shared_release\itk\Wrapping\WrapITK\Typedefs\ITKCommonBase.i(201): warning 394: operator new[] ignored
82>D:\Programming\CC\build\vs10x32_shared_release\itk\Wrapping\WrapITK\Typedefs\ITKCommonBase.i(203): warning 395: operator delete[] ignored
82>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 3.
82>
82>Build FAILED.
82>
82>Time Elapsed 00:05:34.33
Maybe this is a related issue?
|
|
|
|
(0025283)
|
|
Martin Bergtholdt
|
|
2011-02-04 10:53
|
|
With this minimal example you can reproduce the remaining errors:
#include <vector>
void f(std::vector<void*>& va)
{
va.resize(100);
} |
|
|
|
(0025345)
|
|
Brad King
|
|
2011-02-08 17:14
|
|
|
Unfortunately it looks like every new instantiation has the potential to bring in some usage of C++0x features in the VS 10 standard library implementation. We either need to make the patches huge to remove large chunks of the implementation (convert "{...}" to just ";") or need to update gccxml's internal parser to 4.5 or the upcoming 4.6. Neither task is trivial. The former is a maintenance pain. The latter is a huge effort for which I don't know when I'll have time. |
|
|
|
(0034245)
|
|
radbryan
|
|
2013-10-25 14:13
|
|
|
Just curious: what's the current status on this issue? Has there been any work on moving the internal parser toward 4.5 or 4.6? I'm very interested in getting gccxml to work on VS2010 (trying to build Activiz .NET), and would be willing to put some work toward getting that accomplished, even if we just go for the brute force method Brad mentioned in 0025345. |
|
|
|
(0034247)
|
|
Brad King
|
|
2013-10-25 15:00
|
|
|
|
|
(0038310)
|
|
Brad King
|
|
2015-03-26 11:59
|
|
|
vcInstall.cxx (20,181) 2010-11-15 18:27
gxConfiguration.h (5,043) 2010-11-15 18:28
compile_errors.txt (195,695) 2010-11-15 18:31