Thought this went away in my Jan-2023 git pull, but apparently not.
Looked in my dmesg output and saw this again.
process 'sharebin/cingg2301/bin/cin' started with executable stack
Why? A consequence of the plug-in system? a poorly designed 3rdparty
library? an oversight?
--
I think this is due to embedding icon 'object' (lots of png files concatenated) into main executable ...
from cinelerra/Makefile
$(THEME_DATA):
cd $(OBJDIR) && \
$(GUICAST)/$(OBJDIR)/bootstrap theme_data.o $(TOPDIR)/picon/cinfinity/*.png
(also I thought we hoped to optipng them, if quality not suffer ...)
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack
~/cinelerra/cinelerra-5.1 $ readelf -SW cinelerra/aarch64/*.o | grep note | wc -l
374 ~/cinelerra/cinelerra-5.1 $ ls cinelerra/aarch64/*.o | wc -l
375
readelf line from
linker flag from
note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
stack segments are generally marked as no-exec to protect against using
them to execute rogue instructions by saving those instructions in
auto-vars on the stack that could be executed by fudging the return
address of a function.
Just looking for an acknowledgement of this, and any relevant related
history at this point.
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin