As I'm currently working on ede-panel and applet loading code (better to say: "still mocking up the things with it") and in the mean time, all that test on Fedora 10.
After everything worked as charm on Slack (my default distro), this wasn't the case with Fedora; as you guess, SELinux is the problem.
When I started ede-panel, I got warning window with this error:
SELinux is preventing ede-panel from loading (...)/eapplet_demo.so which requires text relocation.Of course, applet wasn't loaded and if this is going to be the case in the future, ede-panel will be pretty unusable because I'm planning to put most of the stuff in applets.
Now, back to SELinux... SELinux offered me the way how to "fix" this with full command line example, but also suggested how this is mostly a bug in the program. Probably it is, but finding text relocations in the code can be very consuming process (that is what people said; I never needed to do this :)).
This is the document explaining what and how, plus mentioning the tool I wasn't aware of: eu-findtextrel". After running it on applet demo, guess: it pointed me on FLTK.
I compile FLTK mostly as static library; don't know why, probably the habit, and when FLTK is compiled as this, -fPIC flag is not used. As above document sais, you have to use it.
So, recompiling FLTK made SELinux happy. This also worries me: FLTK has to be distributed either as shared library (default on Fedora) or it has to use above flag even if compiled as static library (compiling FLTK as static library is default option when FLTK is compiled from source). This is the case only for SELinux enabled distros.
Luckily, FLTK on Fedora already comes as shared library so this is not the problem at all. The only problem is when FLTK is compiled straight from the source code, but at least we have solution, right :)
1 comment:
Fltk static libraries not having -fPIC isn't the problem.
The problem is you linking a static library to a shared library (.so file). Besides requiring the .text (code) segments to be writable (security issue), this will also slow down the process startup and increase memory usage because of the relocations dynamic linker needs to do at the program startup.
In a very large C++ library (say a HTML engine) that doesn't do proper symbol hiding, this can mean several seconds added to startup time and several MBs increase in private/dirty RAM use.
Link static libraries only to executables, then the relocations (within the code, not in relocation tables) can be done at build time, instead of at run-time.
Post a Comment