[2/3] pulseaudio: disable PIE flags when hardened flags are enabled

Message ID c0e598696af9be3f567751a8641effb08431a7d2.1496979431.git.raj.khem@gmail.com
State New
Headers show
Series
  • Fix imagetests with harderning flags
Related show

Commit Message

Khem Raj June 9, 2017, 3:41 a.m.
Fixes

WARNING: pulseaudio-10.0-r0 do_package_qa: QA Issue: ELF binary '/mnt/a/oe/build/tmp/work/i586-bec-linux-musl/pulseaudio/10.0-r0/packages-split/pulseaudio-server/usr/bin/pulseaudio' has relocations in .text [textrel]

This also makes bitbake -c testimage core-image-sato (hardened)
build to pass all tests

Fixes

AssertionError: 1 != 0 : Log: /mnt/a/oe/build/tmp/work/qemux86-bec-linux-musl/core-image-sato/1.0-r0/dmesg_output.log
-----------------------
Central error: [   20.726960] pulseaudio[729]: segfault at 80052b6c ip b771b4fc sp bfc97940 error 7 in libc.so[b76b6000+97000]

Signed-off-by: Khem Raj <raj.khem@gmail.com>

---
 meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.13.1

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Comments

Ross Burton June 9, 2017, 12:55 p.m. | #1
On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:

> +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"

>


These tend to go into security-flags.inc, not the recipe.

Ross
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj June 9, 2017, 1:07 p.m. | #2
On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote:

>

> On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:

>

>> +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"

>>

>

> These tend to go into security-flags.inc, not the recipe.

>


I know that's been the case but I think having a global file is error prone
its better to have it in recipe context since it can get attention at
upgrade time to test if this has been fixed in new release etc

>

> Ross

>
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
André Draszik June 9, 2017, 2:02 p.m. | #3
On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:
> On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote:

> 

> > 

> > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:

> > 

> > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"

> > > 

> > 

> > These tend to go into security-flags.inc, not the recipe.

> > 

> 

> I know that's been the case but I think having a global file is error

> prone

> its better to have it in recipe context since it can get attention at

> upgrade time to test if this has been fixed in new release etc


Isn't one of the main root causes really that bitbake passes -fpie -pie even
when the recipe is building a shared library? (Maybe not in this case here,
though). Obviously, bitbake doesn't really know about shared libraries, and
yes, each recipe's build system could filter out pie flags for shared
library targets, but that's probably better done at libtool level:

http://lists.openembedded.org/pipermail/openembedded-devel/2016-November/110048.html


Cheers,
Andre'

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj June 9, 2017, 2:07 p.m. | #4
On Fri, Jun 9, 2017 at 7:02 AM, André Draszik <git@andred.net> wrote:
> On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:
>> On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote:
>>
>> >
>> > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:
>> >
>> > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
>> > >
>> >
>> > These tend to go into security-flags.inc, not the recipe.
>> >
>>
>> I know that's been the case but I think having a global file is error
>> prone
>> its better to have it in recipe context since it can get attention at
>> upgrade time to test if this has been fixed in new release etc
>
> Isn't one of the main root causes really that bitbake passes -fpie -pie even
> when the recipe is building a shared library?

thats a different case not relevant to this one as much. here we have textrel
in pulseaudio  PIE executable

(Maybe not in this case here,
> though). Obviously, bitbake doesn't really know about shared libraries, and
> yes, each recipe's build system could filter out pie flags for shared
> library targets, but that's probably better done at libtool level:
>
> http://lists.openembedded.org/pipermail/openembedded-devel/2016-November/110048.html
>
>
> Cheers,
> Andre'
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Tanu Kaskinen June 9, 2017, 4:38 p.m. | #5
On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:
> On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote:

> 

> > 

> > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:

> > 

> > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"

> > > 

> > 

> > These tend to go into security-flags.inc, not the recipe.

> > 

> 

> I know that's been the case but I think having a global file is error prone

> its better to have it in recipe context since it can get attention at

> upgrade time to test if this has been fixed in new release etc


Do you mean that there's some bug in pulseaudio, and this is a
workaround for it? Is the bug that there are textrels? Ross saw
textrels in pulseaudio before (see the discussion starting at [1]), but
I was unable to reproduce that. If you give instructions for
reproducing the problem, I'll see if I can fix pulseaudio (until then
I'm fine with having a workaround).

[1] http://lists.openembedded.org/pipermail/openembedded-core/2017-February/133215.html

-- 
Tanu

https://www.patreon.com/tanuk
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj June 9, 2017, 5:10 p.m. | #6
On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote:
> On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:

>> On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote:

>>

>> >

>> > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:

>> >

>> > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"

>> > >

>> >

>> > These tend to go into security-flags.inc, not the recipe.

>> >

>>

>> I know that's been the case but I think having a global file is error prone

>> its better to have it in recipe context since it can get attention at

>> upgrade time to test if this has been fixed in new release etc

>

> Do you mean that there's some bug in pulseaudio, and this is a

> workaround for it? Is the bug that there are textrels? Ross saw

> textrels in pulseaudio before (see the discussion starting at [1]), but

> I was unable to reproduce that. If you give instructions for

> reproducing the problem, I'll see if I can fix pulseaudio (until then

> I'm fine with having a workaround).

>


yes there is a bug lurking when compiling with hardening flags are turned on
so you can do something like

in local.conf

require conf/distro/include/security_flags.inc

then

MACHINE=qemux86 bitbake pulseaudio

it also happens on arm so qemuarm will reproduce it too.

some assembly code is probably missing using GOT relative accesses

> [1] http://lists.openembedded.org/pipermail/openembedded-core/2017-February/133215.html

>

> --

> Tanu

>

> https://www.patreon.com/tanuk

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Tanu Kaskinen April 22, 2019, 12:33 p.m. | #7
On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:
> On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote:

> > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:

> > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote:

> > > 

> > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:

> > > > 

> > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"

> > > > > 

> > > > 

> > > > These tend to go into security-flags.inc, not the recipe.

> > > > 

> > > 

> > > I know that's been the case but I think having a global file is error prone

> > > its better to have it in recipe context since it can get attention at

> > > upgrade time to test if this has been fixed in new release etc

> > 

> > Do you mean that there's some bug in pulseaudio, and this is a

> > workaround for it? Is the bug that there are textrels? Ross saw

> > textrels in pulseaudio before (see the discussion starting at [1]), but

> > I was unable to reproduce that. If you give instructions for

> > reproducing the problem, I'll see if I can fix pulseaudio (until then

> > I'm fine with having a workaround).

> > 

> 

> yes there is a bug lurking when compiling with hardening flags are turned on

> so you can do something like

> 

> in local.conf

> 

> require conf/distro/include/security_flags.inc

> 

> then

> 

> MACHINE=qemux86 bitbake pulseaudio

> 

> it also happens on arm so qemuarm will reproduce it too.

> 

> some assembly code is probably missing using GOT relative accesses


Resurrecting this ancient thread... I finally tried to reproduce this
problem with the given instructions. No success. Have you still been
running into this issue?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj April 22, 2019, 8:28 p.m. | #8
On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen <tanuk@iki.fi> wrote:

> On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:

> > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote:

> > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:

> > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com>

> wrote:

> > > >

> > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:

> > > > >

> > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"

> > > > > >

> > > > >

> > > > > These tend to go into security-flags.inc, not the recipe.

> > > > >

> > > >

> > > > I know that's been the case but I think having a global file is

> error prone

> > > > its better to have it in recipe context since it can get attention at

> > > > upgrade time to test if this has been fixed in new release etc

> > >

> > > Do you mean that there's some bug in pulseaudio, and this is a

> > > workaround for it? Is the bug that there are textrels? Ross saw

> > > textrels in pulseaudio before (see the discussion starting at [1]), but

> > > I was unable to reproduce that. If you give instructions for

> > > reproducing the problem, I'll see if I can fix pulseaudio (until then

> > > I'm fine with having a workaround).

> > >

> >

> > yes there is a bug lurking when compiling with hardening flags are

> turned on

> > so you can do something like

> >

> > in local.conf

> >

> > require conf/distro/include/security_flags.inc

> >

> > then

> >

> > MACHINE=qemux86 bitbake pulseaudio

> >

> > it also happens on arm so qemuarm will reproduce it too.

> >

> > some assembly code is probably missing using GOT relative accesses

>

> Resurrecting this ancient thread... I finally tried to reproduce this

> problem with the given instructions. No success. Have you still been

> running into this issue?



I don’t know for sure if this still exists but we did disable assembly in
few packages which addresses this issue since in assembly PIC has to be
respected
In hand written code

You might have to check if we did something similar for pulseaudio

>

>

> --

> Tanu

>

> https://www.patreon.com/tanuk

> https://liberapay.com/tanuk

>

>
<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen &lt;<a href="mailto:tanuk@iki.fi">tanuk@iki.fi</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:<br>
&gt; On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen &lt;<a href="mailto:tanuk@iki.fi" target="_blank">tanuk@iki.fi</a>&gt; wrote:<br>
&gt; &gt; On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:<br>
&gt; &gt; &gt; On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross &lt;<a href="mailto:ross.burton@intel.com" target="_blank">ross.burton@intel.com</a>&gt; wrote:<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; On 9 June 2017 at 04:41, Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; &gt; +SECURITY_CFLAGS = &quot;${SECURITY_NO_PIE_CFLAGS}&quot;<br>
&gt; &gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; These tend to go into security-flags.inc, not the recipe.<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; I know that&#39;s been the case but I think having a global file is error prone<br>
&gt; &gt; &gt; its better to have it in recipe context since it can get attention at<br>
&gt; &gt; &gt; upgrade time to test if this has been fixed in new release etc<br>
&gt; &gt; <br>
&gt; &gt; Do you mean that there&#39;s some bug in pulseaudio, and this is a<br>
&gt; &gt; workaround for it? Is the bug that there are textrels? Ross saw<br>
&gt; &gt; textrels in pulseaudio before (see the discussion starting at [1]), but<br>
&gt; &gt; I was unable to reproduce that. If you give instructions for<br>
&gt; &gt; reproducing the problem, I&#39;ll see if I can fix pulseaudio (until then<br>
&gt; &gt; I&#39;m fine with having a workaround).<br>
&gt; &gt; <br>
&gt; <br>
&gt; yes there is a bug lurking when compiling with hardening flags are turned on<br>
&gt; so you can do something like<br>
&gt; <br>
&gt; in local.conf<br>
&gt; <br>
&gt; require conf/distro/include/security_flags.inc<br>
&gt; <br>
&gt; then<br>
&gt; <br>
&gt; MACHINE=qemux86 bitbake pulseaudio<br>
&gt; <br>
&gt; it also happens on arm so qemuarm will reproduce it too.<br>
&gt; <br>
&gt; some assembly code is probably missing using GOT relative accesses<br>
<br>
Resurrecting this ancient thread... I finally tried to reproduce this<br>
problem with the given instructions. No success. Have you still been<br>
running into this issue?</blockquote><div dir="auto"><br></div><div dir="auto">I don’t know for sure if this still exists but we did disable assembly in few packages which addresses this issue since in assembly PIC has to be respected</div><div dir="auto">In hand written code </div><div dir="auto"><br></div><div dir="auto">You might have to check if we did something similar for pulseaudio </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
-- <br>
Tanu<br>
<br>
<a href="https://www.patreon.com/tanuk" rel="noreferrer" target="_blank">https://www.patreon.com/tanuk</a><br>
<a href="https://liberapay.com/tanuk" rel="noreferrer" target="_blank">https://liberapay.com/tanuk</a><br>
<br>
</blockquote></div></div>
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Tanu Kaskinen April 26, 2019, 12:53 p.m. | #9
On Mon, 2019-04-22 at 14:28 -0600, Khem Raj wrote:
> On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen <tanuk@iki.fi> wrote:
> 
> > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:
> > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote:
> > > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:
> > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com>
> > wrote:
> > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote:
> > > > > > 
> > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
> > > > > > > 
> > > > > > 
> > > > > > These tend to go into security-flags.inc, not the recipe.
> > > > > > 
> > > > > 
> > > > > I know that's been the case but I think having a global file is
> > error prone
> > > > > its better to have it in recipe context since it can get attention at
> > > > > upgrade time to test if this has been fixed in new release etc
> > > > 
> > > > Do you mean that there's some bug in pulseaudio, and this is a
> > > > workaround for it? Is the bug that there are textrels? Ross saw
> > > > textrels in pulseaudio before (see the discussion starting at [1]), but
> > > > I was unable to reproduce that. If you give instructions for
> > > > reproducing the problem, I'll see if I can fix pulseaudio (until then
> > > > I'm fine with having a workaround).
> > > > 
> > > 
> > > yes there is a bug lurking when compiling with hardening flags are
> > turned on
> > > so you can do something like
> > > 
> > > in local.conf
> > > 
> > > require conf/distro/include/security_flags.inc
> > > 
> > > then
> > > 
> > > MACHINE=qemux86 bitbake pulseaudio
> > > 
> > > it also happens on arm so qemuarm will reproduce it too.
> > > 
> > > some assembly code is probably missing using GOT relative accesses
> > 
> > Resurrecting this ancient thread... I finally tried to reproduce this
> > problem with the given instructions. No success. Have you still been
> > running into this issue?
> 
> I don’t know for sure if this still exists but we did disable assembly in
> few packages which addresses this issue since in assembly PIC has to be
> respected
> In hand written code
> 
> You might have to check if we did something similar for pulseaudio

There seem to be no such changes to the pulseaudio recipe. Some
upstream fix seems unlikely as well. The only possibly relevant change
that I could find was removing a buggy implementation of reading the
cpuid register (the removed code was replaced with the __get_cpuid()
macro that compilers provide in cpuid.h).

Oh well, if the problem reappears, let me know.
Richard Purdie April 26, 2019, 1:52 p.m. | #10
On Fri, 2019-04-26 at 15:53 +0300, Tanu Kaskinen wrote:
> On Mon, 2019-04-22 at 14:28 -0600, Khem Raj wrote:
> > On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen <tanuk@iki.fi> wrote:
> > 
> > > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:
> > > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi>
> > > > wrote:
> > > > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:
> > > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <
> > > > > > ross.burton@intel.com>
> > > wrote:
> > > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
> > > > > > > > 
> > > > > > > 
> > > > > > > These tend to go into security-flags.inc, not the recipe.
> > > > > > > 
> > > > > > 
> > > > > > I know that's been the case but I think having a global
> > > > > > file is
> > > error prone
> > > > > > its better to have it in recipe context since it can get
> > > > > > attention at
> > > > > > upgrade time to test if this has been fixed in new release
> > > > > > etc
> > > > > 
> > > > > Do you mean that there's some bug in pulseaudio, and this is
> > > > > a
> > > > > workaround for it? Is the bug that there are textrels? Ross
> > > > > saw
> > > > > textrels in pulseaudio before (see the discussion starting at
> > > > > [1]), but
> > > > > I was unable to reproduce that. If you give instructions for
> > > > > reproducing the problem, I'll see if I can fix pulseaudio
> > > > > (until then
> > > > > I'm fine with having a workaround).
> > > > > 
> > > > 
> > > > yes there is a bug lurking when compiling with hardening flags
> > > > are
> > > turned on
> > > > so you can do something like
> > > > 
> > > > in local.conf
> > > > 
> > > > require conf/distro/include/security_flags.inc
> > > > 
> > > > then
> > > > 
> > > > MACHINE=qemux86 bitbake pulseaudio
> > > > 
> > > > it also happens on arm so qemuarm will reproduce it too.
> > > > 
> > > > some assembly code is probably missing using GOT relative
> > > > accesses
> > > 
> > > Resurrecting this ancient thread... I finally tried to reproduce
> > > this
> > > problem with the given instructions. No success. Have you still
> > > been
> > > running into this issue?
> > 
> > I don’t know for sure if this still exists but we did disable
> > assembly in
> > few packages which addresses this issue since in assembly PIC has
> > to be
> > respected
> > In hand written code
> > 
> > You might have to check if we did something similar for pulseaudio
> 
> There seem to be no such changes to the pulseaudio recipe. Some
> upstream fix seems unlikely as well. The only possibly relevant
> change
> that I could find was removing a buggy implementation of reading the
> cpuid register (the removed code was replaced with the __get_cpuid()
> macro that compilers provide in cpuid.h).
> 
> Oh well, if the problem reappears, let me know.

Shortly after this, Khem submitted:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c91314ec160420a320007d552cec6c7da4d54833
and 
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6733a7873ca121295a2e309a6915b9816e1ae36b

which I suspect made this other change unnecessary?

Cheers,

Richard

Patch

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb
index f3a85737fc..3ea35e592a 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb
@@ -8,6 +8,8 @@  SRC_URI = "http://freedesktop.org/software/pulseaudio/releases/${BP}.tar.xz \
 SRC_URI[md5sum] = "4950d2799bf55ab91f6b7f990b7f0971"
 SRC_URI[sha256sum] = "a3186824de9f0d2095ded5d0d0db0405dc73133983c2fbb37291547e37462f57"
 
+SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
+
 do_compile_prepend() {
     mkdir -p ${S}/libltdl
     cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl