swftools-common
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Swftools-common] Re: cannot compile swftools under Fedora 14


From: Nick Soracco
Subject: [Swftools-common] Re: cannot compile swftools under Fedora 14
Date: Wed, 2 Feb 2011 19:29:37 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Pablo Rodríguez <address@hidden> writes:

> 
> On 12/06/2010 09:28 AM, Mohamed El Morabity wrote:
> > Le lundi 06 décembre 2010 à 08:44 +0100, Pablo Rodríguez a écrit :
> >> I had these repositories added and I had all BuildRequires from your
> >> srpm installed, but there is a non-listed dependency that is preventing
> >> me from compiling swftools myself.
> > How strange... What is that missing dependency?
> 
> If I knew the dependency, I'd have solved the issue .
> 
> I guess there is a missing dependency, because I was able to compile 
> swftools under Fedora 13.
> 
> Another guess is that he system might be trying to compile it as a 64bit 
> binary (but I don't think so).
> 
> > How do you rebuild the package?
> 
> rpmbuild --rebuild --clean swftools-0.9.1-2.fc14.src.rpm
> 
> Thanks for your help,

This isn't a dependency problem at all.  I've had my own custom spec/rpm built
for swftools since 2008 (I'll be happy to provide it if you like). 

The problem is related to a new SELinux policy.  You'll find that if you
rebuild/recompile with SELinux temporarily turned off (sudo setenforce 0) the
build will complete. 

I personally believe SELinux is a valuable tool.  The problem lies with the
autotools configuration program for freetype.  I believe it needs to be modified
to work with a non-executable stack (the original error was: "error while
loading shared libraries: libpdf.so.6: cannot enable executable stack as shared
object requires: Permission denied").

The solution is to either wholsesale disable SELinux, or, if you prefer a more
granular approach (as I do), set the following boolean to true: allow_execstack 

i.e.: sudo setsebool allow_execstack on

Then rebuild the RPM.

You can turn it off permanently by using the -P flag to setsebool, but since the
problem only appears to arise during compilation, it should be safe to only
disable it then and re-enable it after installation.  Especially since you
report the RPM's the other fellow built worked for you after you installed them,
you simply couldn't build them yourself.

HTH, 

Nick




reply via email to

[Prev in Thread] Current Thread [Next in Thread]