David Cournapeau wrote:
> Andrew Jaffe wrote:
>> Hi All,
>>
>> I have just switched from RHEL to debian, and all of a sudden I started
>> getting floating point exception errors in various contexts.
>>
>> Apparently, this has to do with some faulty error stuff in glibc,
>> specifically related to the sse. I would prefer to fix the actual
>> problem, but I can't seem to be able to get the recommended 'apt-get
>> source glibc' incantation to work (I'm not root, but I can sudo.)
>>
> What does not work ? The apt-get source part ? The actual building ?
>
> Basically, if the sources are OK, you just need to do
> - fakeroot dpkg-source -x name_of_dsc_file
> - cd name_of_package
> - fakeroot dpkg-buildpackage
>
> And that's it
Aha -- I didn't know about fakeroot... Thanks! That was the problem with
apt-get source. I'm compiling the patched version now... wow, is it slow!
>> I was able to fix some of these issues by simply downgrading ATLAS to
>> not use sse instructions anymore.
>>
>> But f2py still links with sse and sse2 by default. I can't quite
>> understand the configuration well enough to work out how to turn it off.
>> Can someone give me any guidance?
>>
> The way it is supposed to work, at least on debian and ubuntu, is that
> you never link to the sse/sse2 versions, but to the non-optimized
> versions. After, the dynamic loader will get the right one (ie optimized
> if available) instead of the one linked (this of course only works for
> dynamic linking). You can check which library is picked with a ldconfig
> - p | grep lapack (for lapack functions, and so on...)
The problem with f2py isn't the atlas/lapack linkage, which it does
correctly, but the fact that it automatically appends -sse2 to the g77
compile options; I couldn't figure out how to turn that off! Although
now I'm not so sure, since I can never get my self-compiled executable
version of my fortran code to give the same error as when it runs within
python.
But with the patched glibc, I think I'm alright in any event!
Thanks!
A
|
