This comes up so often that I think someone (maybe even me?) must have written a few scripts to help with this, and certainly a FAQ or something. It's quite easy to track down how this comes about if you have a build of the thing in question and examine its object files. By checking the ELF section headers of each individual object file, you can see which ones have the executable-stack marker--it only takes one to get the entire DSO or program binary marked executable. Roughly, "readelf -S x.o | grep GNU-stack". X marks the spot. :-) Once you've located the object files in question and found their sources, there are two common cases that are producing this. One is assembly code (usually .s or .S files); bare assembly files get no marker, and no marker defaults to meaning marked executable. In the assembly code, just add: .section .note.GNU-stack .previous That is, unless you think the assembly code might actually use executable stack. That you'll have to figure out, but it's an unusual thing for some assembly code to do. If it does, make that: .section .note.GNU-stack, "x". The other common situation is nested functions (a GCC extension in C code). These can sometimes be made nested inline functions, and optimized away. Other times it's not hard to just make them static functions. Sometimes nested functions are nice to have and it makes the code hairier to avoid them, so you just want to leave them and acknowledge that executable stack is going to be required for that program or library.
