Re: [Math-atlas-devel] Executable Stack errors

[<rw...@cs...>]

Quentin,

>So, I installed Fedora Extras ATLAS package (I'm the maintainer) on the 
>test release for the upcoming Fedora Core 5. When I tried to start 
>octave, I got the following error:
>
>octave: error while loading shared libraries: libblas.so.3: cannot 
>enable executable stack as shared object requires: Permission denied
>
>Removing ATLAS and installing the base blas and lapack, the problem went 
>away. After asking on some mailing lists, I found that the reason I 
>hadn't seen this error before is that I had SELinux disabled in the FC4 
>setup I normally use, but it was apparently enabled in the test system 
>and it was enforcing security policies that forbid executing code in the 
>stack, while the ATLAS shared libraries had a flag set saying they 
>required it. My question is, is this necessary or by accident?
>
>After some further reading (see 
>http://www.gentoo.org/proj/en/hardened/gnu-stack.xml and 
>http://people.redhat.com/drepper/selinux-mem.html), it seems that this 
>sort of thing can often be caused inadvertently by assembly code, as gcc 
>doesn't allow this by default. The fix seems to be either modifying the 
>assembly code to set the necessary flags or to compile with 
>--noexecstack. If I compile with --noexecstack, would it break anything 
>in ATLAS?

ATLAS certainly does not execute any code on the stack; it does no dynamic
code generation at all.  I'm not familiar with --noexecstack, and my
gcc docs don't list it, but as long as it only asserts that we aren't
executing code who's instructions have been generated on the stack, then
indeed it is safe to throw it in ATLAS.

>I should also note that in the Fedora packages, I'm using 3.6.0 with the 
>Debian patches, which appear to include some backports of various 3.7.x 
>features, though I doubt that affects this particular issue very much.

Hopefully we'll get a new stable out next summer . . .

Cheers,
Clint