Error compiling trunk using MSVS 9 (Trac #973)

[thouis]

Original ticket http://projects.scipy.org/numpy/ticket/973 on 2008-12-19 by @FrancescAlted, assigned to unknown.

FYI. After trying to compile the NumPy trunk with MSVS 9 (32-bits), I'm getting the next error:

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo
/INCREMENTAL:NO /LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\PCbuild /EXPORT:i
nitmtrand build\temp.win32-2.6\Release\numpy\random\mtrand\mtrand.obj build\temp
.win32-2.6\Release\numpy\random\mtrand\randomkit.obj build\temp.win32-2.6\Releas
e\numpy\random\mtrand\initarray.obj build\temp.win32-2.6\Release\numpy\random\mt
rand\distributions.obj /OUT:build\lib.win32-2.6\numpy\random\mtrand.pyd /IMPLIB:
build\temp.win32-2.6\Release\numpy\random\mtrand\mtrand.lib /MANIFESTFILE:build\
temp.win32-2.6\Release\numpy\random\mtrand\mtrand.pyd.manifest
   Creating library build\temp.win32-2.6\Release\numpy\random\mtrand\mtrand.lib
and object build\temp.win32-2.6\Release\numpy\random\mtrand\mtrand.exp
randomkit.obj : error LNK2019: unresolved external symbol __imp__CryptReleaseCon
text@8 referenced in function _rk_devfill
randomkit.obj : error LNK2019: unresolved external symbol __imp__CryptGenRandom@
12 referenced in function _rk_devfill
randomkit.obj : error LNK2019: unresolved external symbol __imp__CryptAcquireCon
textA@20 referenced in function _rk_devfill
build\lib.win32-2.6\numpy\random\mtrand.pyd : fatal error LNK1120: 3 unresolved
externals
error: Command "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.e
xe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\P
Cbuild /EXPORT:initmtrand build\temp.win32-2.6\Release\numpy\random\mtrand\mtran
d.obj build\temp.win32-2.6\Release\numpy\random\mtrand\randomkit.obj build\temp.
win32-2.6\Release\numpy\random\mtrand\initarray.obj build\temp.win32-2.6\Release
\numpy\random\mtrand\distributions.obj /OUT:build\lib.win32-2.6\numpy\random\mtr
and.pyd /IMPLIB:build\temp.win32-2.6\Release\numpy\random\mtrand\mtrand.lib /MAN
IFESTFILE:build\temp.win32-2.6\Release\numpy\random\mtrand\mtrand.pyd.manifest"
failed with exit status 1120

I regularly use MSVS 9 to compile trunk, but I've never seen this error before.

[thouis]

@cournape wrote on 2008-12-23

Which Platform SDK are you using ? I don't see this problem with the compiler from PSDK 6.1

[thouis]

@FrancescAlted wrote on 2008-12-23

Sorry, but I don't know what a Platform SDK is. The only thing that I know is that I'm using Microsoft Visual Studio 2008 (free edition) on top of Windows Vista.

[thouis]

@cournape wrote on 2008-12-23

Ah yes, sorry, I was mislead by Program Files (x86). I assumed that you built for 64 bits - and no free VS can do that, the only free version of MS compilers targeting 64 bits are through the Windows / Platform SDK.

Anyway, I don't see this error with MSVC 9 on a 32 bits windows, so I am wondering whether this is a problem with building for 32 bits from a 64 bits OS. Since this is basically cross compiling, I would have actually been surprised if that worked. I will look into it, but I am afraid it won't be easy. You are using 32 bits or 64 bits python ?

[thouis]

@FrancescAlted wrote on 2008-12-23

Well, the compiler is 32-bit, yes, but I'm not sure about the python version (I'm away from the office now, so I can't check that until after the new year). However, I'm sure that Vista is 64-bit. It is strange, because I've compiled several times in this platform an updated version of !NumPy trunk during November and it worked perfectly. The problem should be something introduced after that date.

OTOH, it may perfectly happen that the problem has gone away, although I can't check this on my platform until I get back to office (by January, 7th). Thanks for looking into this anyway.

[thouis]

@FrancescAlted wrote on 2008-12-23

Now that I think, perhaps the problem was that I have not done a clean-up of the build directory before re-compiling. This is to say that, if you can't reproduce the issue, then most probably the problem is on my side. Feel free to close the ticket then. When I go back to the office, I'll try again and if the problem continue, will re-open the ticket.

Cheers

[thouis]

@FrancescAlted wrote on 2009-01-07

I'm back to the office and tried with a fresh trunk version: the compilation went well now. So I think you can close this ticket safely now.

FWIW, I've run the test suite and got some errors:

Running unit tests for numpy
NumPy version 1.3.0.dev6298
NumPy is installed in C:\Python26\lib\site-packages\numpy
Python version 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)
]
nose version 0.10.4
<clip>
----------------------------------------------------------------------
Ran 1651 tests in 4.875s

FAILED (KNOWNFAIL=1, SKIP=1, failures=18)

but all seem related with the output formatting that you are working out, something like:

======================================================================
FAIL: Check formatting when using print
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python26\lib\site-packages\nose\case.py", line 182, in runTest
    self.test(*self.arg)
  File "C:\Python26\lib\site-packages\numpy\core\tests\test_print.py", line 115,
 in check_complex_type_print
    _test_redirected_print(complex(x), tp)
  File "C:\Python26\lib\site-packages\numpy\core\tests\test_print.py", line 104,
 in _test_redirected_print
    err_msg='print failed for type%s' % tp)
  File "C:\Python26\Lib\site-packages\numpy\testing\utils.py", line 183, in asse
rt_equal
    raise AssertionError(msg)
AssertionError:
Items are not equal: print failed for type<type 'numpy.complex128'>
 ACTUAL: '(1e+20+0j)\n'
 DESIRED: '(1e+020+0j)\n'

or:

======================================================================
FAIL: test_print.test_locale_single
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python26\lib\site-packages\nose\case.py", line 182, in runTest
    self.test(*self.arg)
  File "C:\Python26\Lib\site-packages\numpy\testing\decorators.py", line 82, in
skipper
    return f(*args, **kwargs)
  File "C:\Python26\lib\site-packages\numpy\core\tests\test_print.py", line 164,
 in test_locale_single
    return _test_locale_independance(np.float32)
  File "C:\Python26\lib\site-packages\numpy\core\tests\test_print.py", line 157,
 in _test_locale_independance
    err_msg='Failed locale test for type %s' % tp)
  File "C:\Python26\Lib\site-packages\numpy\testing\utils.py", line 183, in asse
rt_equal
    raise AssertionError(msg)
AssertionError:
Items are not equal: Failed locale test for type <type 'numpy.float32'>
 ACTUAL: '1,2'
 DESIRED: '1.2'

But I guess that you are already aware of these.

Thanks!

[thouis]

@stefanv wrote on 2009-01-07

Thanks for the feedback, Francesc. Those two problems are known: one is Python 2.6 related and the other is due to your French locale. We'll have them both fixed for the 1.3 release.