[Numpy-discussion] Segfault in mingw in test_arrayprint.TestComplexArray

Ondřej Čertík ondrej.certik@gmail....
Tue Jul 24 19:06:49 CDT 2012


On Tue, Jul 24, 2012 at 5:04 PM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
> On Tue, Jul 24, 2012 at 3:58 PM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
>> Ralf,
>>
>>>> David, what version of binutils do you use?
>>>> I use 2.17.50 (https://github.com/certik/numpy-vendor)
>>>> and maybe that's the problem, that the objdump from there
>>>> can't read the msvcr library.
>>>>
>>>> I use gcc 3.4.5. What exact version do you use in wine?
>>>>
>>>
>>> I have gcc 3.4.5 and binutils 2.20. I'll send you a tar file with all the
>>> binaries off-list. Apologies in advance for clogging your inbox.
>>
>> Thanks a lot for this. It helped a lot.
>>
>>
>> I got your binutils 2.20, installed (into a clean .wine environment),
>> and used the original numpy code
>> from the maintenance/1.7.x, it still fails with the "ValueError:
>> Symbol table not found" exception
>> due to this problem:
>>
>>
>> Z:\home\ondrej>objdump -t
>> C:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef\msvcr90.dll
>> objdump: C:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef\msvcr90.dll:
>> File format not recognized
>>
>>
>> My binutils are correct now:
>>
>>
>> Z:\home\ondrej>objdump --version
>> GNU objdump (GNU Binutils) 2.20
>> Copyright 2009 Free Software Foundation, Inc.
>> This program is free software; you may redistribute it under the terms of
>> the GNU General Public License version 3 or (at your option) any later version.
>> This program has absolutely no warranty.
>>
>>
>> So now I know that the problem is not there, and so it must be in my
>> msvcr90.dll library somehow. I will keep digging.
>
> I've meed a little progress. Here are all my msvcr90.dll on my system:
>
> ondrej@eagle:~/.wine$ find . -name msvcr90.dll
> ./drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll
> ./drive_c/windows/winsxs/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375/msvcr90.dll
> ./drive_c/windows/system32/msvcr90.dll
>
>
> since the "deadbeef" one gets picked up by numpy and it doesn't work,
> I did the following:
>
> rm ./drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll
>
> And now numpy gets further:
>
> Building msvcr library: "C:\Python27\libs\libmsvcr90.a" (from
> C:\windows\winsxs\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375\msvcr90.dll)
> Cannot build msvcr library: "msvcr90d.dll" not found
>
>
>
> The msvcr90d.dll is some debugging version of the library, which
> indeed is not even installed in my wine.
>
> So I did some debugging of the build_msvcr_library() function in
> numpy/distutils/mingw32ccompiler.py and it turns out
> that when it is called with debug=False, it indeed builds the new
> library in C:\Python27\libs\libmsvcr90.a.
> When called with debug=True, it simply prints the message that
> msvcr90d.dll was not found, but this should be harmless.
>
> So this looks like things are actually working for me. Except that
> later, I get this error:
>
> Found executable C:\MinGW\bin\g++.exe
> C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
> cannot find -lmsvcr90
> collect2: ld returned 1 exit status
> 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 "Z:\home\ondrej\repos\numpy\numpy\distutils\core.py", line 186, in setup
>     return old_setup(**new_attr)
>   File "C:\Python27\lib\distutils\core.py", line 152, in setup
>     dist.run_commands()
>   File "C:\Python27\lib\distutils\dist.py", line 953, in run_commands
>     self.run_command(cmd)
>   File "C:\Python27\lib\distutils\dist.py", line 972, in run_command
>     cmd_obj.run()
>   File "Z:\home\ondrej\repos\numpy\numpy\distutils\command\build.py",
> line 37, in run
>     old_build.run(self)
>   File "C:\Python27\lib\distutils\command\build.py", line 127, in run
>     self.run_command(cmd_name)
>   File "C:\Python27\lib\distutils\cmd.py", line 326, in run_command
>     self.distribution.run_command(command)
>   File "C:\Python27\lib\distutils\dist.py", line 972, in run_command
>     cmd_obj.run()
>   File "Z:\home\ondrej\repos\numpy\numpy\distutils\command\build_src.py",
> line 152, in run
>     self.build_sources()
>   File "Z:\home\ondrej\repos\numpy\numpy\distutils\command\build_src.py",
> line 163, in build_sources
>     self.build_library_sources(*libname_info)
>   File "Z:\home\ondrej\repos\numpy\numpy\distutils\command\build_src.py",
> line 298, in build_library_sources
>     sources = self.generate_sources(sources, (lib_name, build_info))
>   File "Z:\home\ondrej\repos\numpy\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
>
>
> The reason is that "ld" doesn't find the msvcr90.dll. If I copy the
> right one into C:\MinGW\lib, then it starts working. But I think that
> this copying by hand should not be done...

But --- I can run all numpy tests for the first time!!

Here are the failures:


======================================================================
ERROR: test_datetime_y2038 (test_datetime.TestDateTime)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\numpy\core\tests\test_datetime.py",
line 1749, in test_datetime_y2038
    assert_equal(str(a)[:-5], '2038-01-20T13:21:14')
OSError: Failed to use '_localtime64_s' to convert to a local time

======================================================================
ERROR: test_combinations (test_multiarray.TestArgmax)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\numpy\core\tests\test_multiarray.py",
line 1280, in test_combinations
    assert_equal(np.argmax(arr), pos, err_msg="%r"%arr)
OSError: Failed to use '_localtime64_s' to convert to a local time

======================================================================
ERROR: test_combinations (test_multiarray.TestArgmin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\numpy\core\tests\test_multiarray.py",
line 1348, in test_combinations
    assert_equal(np.argmin(arr), pos, err_msg="%r"%arr)
OSError: Failed to use '_localtime64_s' to convert to a local time

----------------------------------------------------------------------
Ran 4258 tests in 21.161s

FAILED (KNOWNFAIL=9, SKIP=8, errors=3)



Ondrej


More information about the NumPy-Discussion mailing list