On Mon, Nov 12, 2012 at 1:31 PM, Peter Cock <[email protected]>wrote:
> On Sun, Nov 11, 2012 at 11:20 PM, Peter Cock <[email protected]> > wrote: > > On Sun, Nov 11, 2012 at 9:05 PM, Ralf Gommers <[email protected]> > wrote: > >> > >> Those changes look correct, a PR would be great. > >> > > > > I'll do that later this week - but feel free to do it yourself > immediately > > if more convenient. > > > > Hi again Ralf, > > OK, new branch from the master here: > https://github.com/peterjc/numpy/tree/msvc10 > > The first two commits are the changes already discussed. > > https://github.com/peterjc/numpy/commit/d8ead4c83364f9c7d4543690eb12e4543c608372 > > https://github.com/peterjc/numpy/commit/1d498f54668a9a87286fa31f2779acbb048edd39 > > >> Fixing the next error also seems straightforward; around line 465 of > >> mingw32ccompiler a check is needed for 10.0 (not sure which one) > >> and then a line like > >> _MSVCRVER_TO_FULLVER['10'] = "10.0.xxxxx.x" > >> needs to be added. > > > > I'd got that far last night before calling turning in - my question was > > where do I get the last two parts of the version number. Presumably > > I can just use the values from the msvcr100.dll on my machine? > > The third commit provides a fall back value (based on the DLL on > my machine) as done for MSVC v8 and v9, and updates the live > lookup via msvcrt.CRT_ASSEMBLY_VERSION to actually check > what version that is (the current code wrongly assumes it is going > to be for MSCV v9): > > https://github.com/peterjc/numpy/commit/24523565b5dbb23d6de0591ef2a4c1d014722c5d > > Do you want a pull request for that work so far? Or can you > suggest what I should investigate next since there is at least > one more hurdle to clear before I can build it (build output below). > It would be easier to only have to test this once, so let's try to get it all resolved. > > > I now get further trying to build with mingw32 (from this branch > from master, not the numpy-1.7.0b2 files this time), an excerpt > from which this line may be note-worthy: > > Cannot build msvcr library: "msvcr100d.dll" not found > > This omits the failure to detect ALTAS etc which seems irrelevant. > I would guess the MismatchCAPIWarning is an unrelated issue > from working from the master branch this time. > That's indeed unrelated. You get that warning each time something is added to the C API without an update to the API version number. That version number update is usually only done right before a release. > > C:\repositories\numpy>c:\python33\python setup.py build --compiler=mingw32 > Converting to Python3 via 2to3... > <snip> > numpy\core\setup_common.py:86: MismatchCAPIWarning: API mismatch > detected, the C API version numbers have to be updated. Current C api > version is 8, with checksum f4362353e2d72f889fda0128aa015037, but > recorded checksum for C API version 8 in codegen_dir/cversions.txt is > 17321775fc884de0b1eda478cd61c74b. If functions were added in the C > API, you have to update C_API_VERSION in numpy\core\setup_common.py. > MismatchCAPIWarning) > <snip> > running build > running config_cc > unifing config_cc, config, build_clib, build_ext, build commands > --compiler options > running config_fc > unifing config_fc, config, build_clib, build_ext, build commands > --fcompiler options > running build_src > build_src > building py_modules sources > building library "npymath" sources > Cannot build msvcr library: "msvcr100d.dll" not found > Unable to find productdir in registry > Checking environ VS100COMNTOOLS > customize GnuFCompiler > Could not locate executable g77 > Could not locate executable f77 > customize IntelVisualFCompiler > Could not locate executable ifort > Could not locate executable ifl > customize AbsoftFCompiler > Could not locate executable f90 > customize CompaqVisualFCompiler > Found executable C:\cygwin\bin\DF.exe > Found executable C:\cygwin\bin\DF.exe > customize IntelItaniumVisualFCompiler > Could not locate executable efl > customize Gnu95FCompiler > Could not locate executable gfortran > Could not locate executable f95 > customize G95FCompiler > Could not locate executable g95 > customize IntelEM64VisualFCompiler > customize IntelEM64TFCompiler > Could not locate executable efort > Could not locate executable efc > don't know how to compile Fortran code on platform 'nt' > C compiler: gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes > > compile options: '-DNPY_MINGW_USE_CUSTOM_MSVCR > -D__MSVCRT_VERSION__=0x1000 -Inumpy\core\src\private -Inumpy\core\src > -Inumpy\core -Inumpy\core\src\npymath -Inumpy\core\src\multiarray > -Inumpy\core\src\umath -Inumpy\core\src\npysort -Inumpy\core\include > -Ic:\python33\include -Ic:\python33\include -c' > gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes > -DNPY_MINGW_USE_CUSTOM_MSVCR -D__MSVCRT_VERSION__=0x1000 > -Inumpy\core\src\private -Inumpy\core\src -Inumpy\core > -Inumpy\core\src\npymath -Inumpy\core\src\multiarray > -Inumpy\core\src\umath -Inumpy\core\src\npysort -Inumpy\core\include > -Ic:\python33\include -Ic:\python33\include -c _configtest.c -o > _configtest.o > Found executable C:\cygwin\usr\bin\gcc.exe > g++ -mno-cygwin _configtest.o -lmsvcr100 -o _configtest.exe > Could not locate executable g++ > Executable g++ does not exist > A C++ compiler shouldn't be needed for numpy, so it shouldn't try to find one. On Linux it doesn't try this. It looks like on Windows (with MinGW at least) it does. I looked at a build log from a compile with MinGW and g++ available ( http://projects.scipy.org/numpy/attachment/ticket/1909/dc6b601-builld.log), and g++ is used exactly once: for the linking stage of numpy.core._dummy.pyd. Looking at core/setup.py that is related to __STDC_FORMAT_MACROS. That led me to https://github.com/numpy/numpy/commit/64423fdb18e8. So the easy way forward is to install g++. The hard way is figuring out why that define was necessary and find a way around it. Ralf > failure. > removing: _configtest.exe.manifest _configtest.c _configtest.o > Traceback (most recent call last): > File "setup.py", line 214, in <module> > setup_package() > File "setup.py", line 207, in setup_package > configuration=configuration ) > File "C:\repositories\numpy\build\py3k\numpy\distutils\core.py", line > 186, in > setup > return old_setup(**new_attr) > File "c:\python33\lib\distutils\core.py", line 148, in setup > dist.run_commands() > File "c:\python33\lib\distutils\dist.py", line 917, in run_commands > self.run_command(cmd) > File "c:\python33\lib\distutils\dist.py", line 936, in run_command > cmd_obj.run() > File > "C:\repositories\numpy\build\py3k\numpy\distutils\command\build.py", line > 37, in run > old_build.run(self) > File "c:\python33\lib\distutils\command\build.py", line 126, in run > self.run_command(cmd_name) > File "c:\python33\lib\distutils\cmd.py", line 313, in run_command > self.distribution.run_command(command) > File "c:\python33\lib\distutils\dist.py", line 936, in run_command > cmd_obj.run() > File > "C:\repositories\numpy\build\py3k\numpy\distutils\command\build_src.py", > line 152, in run > self.build_sources() > File > "C:\repositories\numpy\build\py3k\numpy\distutils\command\build_src.py", > line 163, in build_sources > self.build_library_sources(*libname_info) > File > "C:\repositories\numpy\build\py3k\numpy\distutils\command\build_src.py", > line 298, in build_library_sources > sources = self.generate_sources(sources, (lib_name, build_info)) > File > "C:\repositories\numpy\build\py3k\numpy\distutils\command\build_src.py", > line 385, in generate_sources > source = func(extension, build_dir) > File "numpy\core\setup.py", line 648, in get_mathlib_info > raise RuntimeError("Broken toolchain: cannot link a simple C program") > RuntimeError: Broken toolchain: cannot link a simple C program > > > Peter > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
