Hi Robert, Attached is the complete output, below is what I believe is the relevant area of interest:
compiling C sources
creating build\temp.win-amd64-2.6\Release\build
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core
creating
build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c
/nologo /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src
-Inumpy\core\include -Ibuild\src.win-amd64-2.6\numpy\core -Inumpy\core\src
-Inumpy\core\include -IC:\Python26\include -IC:\Python26\PC
-IC:\Python26\include -IC:\Python26\PC
/Tcbuild\src.win-amd64-2.6\numpy\core\src\umathmodule.c
/Fobuild\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src\umathmodule.obj
umathmodule.c
numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'
numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
numpy\core\src\ufuncobject.c(1645) : warning C4244: '=' : conversion from
'npy_intp' to 'int', possible loss of data
numpy\core\src\ufuncobject.c(2346) : warning C4244: '=' : conversion from
'npy_intp' to 'int', possible loss of data
What I find odd is that the instruction:
> #ifndef HAVE_FREXPF
should not produce the error (at least that's what I would have thought)
i.e. if it isn't recognised the compiler should simply be using the
alternate definition of the frexpf function defined, although I suspect it
is a little less efficient than the float one from the libs.
Hanni
2008/6/3 Robert Kern <[EMAIL PROTECTED]>:
> On Tue, Jun 3, 2008 at 3:21 AM, Hanni Ali <[EMAIL PROTECTED]> wrote:
> > Hi David,
> >
> > I compiled numpy with MSVC 9.0 (vs 2008), I am just using the inbuilt LA
> > libs to minimise complexity.
> >
> > Although I have hacked it such that I can compile and all but one of the
> > regression tests passed:
> >
> > ======================================================================
> > ERROR: Tests reading from a text file.
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "C:\Python26\lib\site-packages\numpy\ma\tests\test_mrecords.py",
> line
> > 363
> > , in test_fromtextfile
> > fname = 'tmp%s' % datetime.now().strftime("%y%m%d%H%M%S%s")
> > ValueError: Invalid format string
> > ----------------------------------------------------------------------
> > Ran 1267 tests in 1.141s
> > FAILED (errors=1)
> > <unittest._TextTestResult run=1267 errors=1 failures=0>
> >
> > This appears to be a problem with the strftime function in
> test_mrecords.py
> >
> > The error seems to be created by the millisecond formatting argument %s,
> > removing this caused the test to pass.
>
> Well, this should be using tempfile anyways.
>
> > So I think it's all ok really, however in order to get numpy to compile I
> > have commented out a small part which was causing compilation to fail:
> >
> > numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'
> > numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
> >
> > This relates to this section of code:
> >
> > #ifndef HAVE_FREXPF
> > static float frexpf(float x, int * i)
> > {
> > return (float)frexp((double)(x), i);
> > }
> > #endif
> > #ifndef HAVE_LDEXPF
> > static float ldexpf(float x, int i)
> > {
> > return (float)ldexp((double)(x), i);
> > }
> > #endif
> >
> > The compiler directives HAVE_FREXPF and HAVE_LDEXPF do not appear to be
> > recognised by msvc 9 would you agree with that assessment?
> >
> > And a redefinition of a function present in the stdc library is
> occurring.
> >
> > What do you think? By just commenting out this piece of code numpy
> compiles
> > and appears to function.
>
> The presence of these functions should have been detected by the
> configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have
> been #define'd if we had detected them correctly. It is possible that
> our configuration process for this does not work correctly with VS
> 2008. From a clean checkout, can you please do the build again and
> copy-and-paste everything printed to the terminal?
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
output.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
