package/clamav: fix build with uClibc

clamav wants to use backtrace, and decides whether it can use it if it
detects a glibc >= 2.1.

But uClibc does impersonate a glibc >= 2.1, so clamav concludes it is
possible to use backtrace. So it includes execinfo.h, which is missing
in our default uClibc config file.

So, just extend the test so that backtrace support is disable on uClibc,
unless it has been configured with backtrace support.

A far better solution would be to add a ./configure check for backtrace,
but this patch is sufficient enough.

Fixes:
    http://autobuild.buildroot.net/results/cff/cffa32fcedda735983d4805d6d4fa77844539b10/
    http://autobuild.buildroot.net/results/e0a/e0a765a94a538b0b936ea512f7aba0264fac6309/
    ...

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 package/clamav/clamav-0003-backtrace-uClibc.patch | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 package/clamav/clamav-0003-backtrace-uClibc.patch

"Yann E. MORIN" <yann.morin.1998@free.fr> wrote in 
news:1416155667-21771-1-git-send-email-yann.morin.1998@free.fr:

> So, just extend the test so that backtrace support is disable on uClibc,
> unless it has been configured with backtrace support.

Hi,

thanks, your patch supersedes http://patchwork.ozlabs.org/patch/406336/

Please add the upstream bugtracker URL to your patch: 
https://bugzilla.clamav.net/show_bug.cgi?id=11170

Acked-by: Bernd Kuhls <bernd.kuhls@t-online.de>

Regards, Bernd

Bernd, All,

On 2014-11-16 18:21 +0100, Bernd Kuhls spake thusly:
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote in 
> news:1416155667-21771-1-git-send-email-yann.morin.1998@free.fr:
> 
> > So, just extend the test so that backtrace support is disable on uClibc,
> > unless it has been configured with backtrace support.
> thanks, your patch supersedes http://patchwork.ozlabs.org/patch/406336/

Damn, it seems I should look in our patchwork before fixing bugs. ;-)

Thanks for pointing this out.

> Please add the upstream bugtracker URL to your patch: 
> https://bugzilla.clamav.net/show_bug.cgi?id=11170

OK, I'll add it locally, but hopefully the maintainer can just stick
this URL when he commits. :-p

Regards,
Yann E. MORIN.

Dear Bernd Kuhls,

On Sun, 16 Nov 2014 18:21:04 +0100, Bernd Kuhls wrote:

> Please add the upstream bugtracker URL to your patch: 
> https://bugzilla.clamav.net/show_bug.cgi?id=11170

I believe Yann's patch is not an appropriate upstream solution, and a
configure.ac check should be added instead.

Thomas

Thomas, All,

On 2014-11-16 22:02 +0100, Thomas Petazzoni spake thusly:
> On Sun, 16 Nov 2014 18:21:04 +0100, Bernd Kuhls wrote:
> 
> > Please add the upstream bugtracker URL to your patch: 
> > https://bugzilla.clamav.net/show_bug.cgi?id=11170
> 
> I believe Yann's patch is not an appropriate upstream solution, and a
> configure.ac check should be added instead.

That's what I think, too. But see what Peter had to say about that (as
pointed out by Bernd):
    http://patchwork.ozlabs.org/patch/406336/

Now, upstream has both patches in their bug tracker: the original from
Bernd that adds a check in ./configure (well, rather in
m4/reorganization/headers.m4, but that gives a configure-time check),
and my patch, does just slightly expands the current test to recognise
uClibc.

It's now to upstream to decide what they want.

But back to Buildroot: we need a fix before the release, and that patch
is what Peter asked for.

I don't care whichever we use, though. ;-)

Regards,
Yann E. MORIN.

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Dear Bernd Kuhls,
 > On Sun, 16 Nov 2014 18:21:04 +0100, Bernd Kuhls wrote:

 >> Please add the upstream bugtracker URL to your patch: 
 >> https://bugzilla.clamav.net/show_bug.cgi?id=11170

 > I believe Yann's patch is not an appropriate upstream solution, and a
 > configure.ac check should be added instead.

Well, you could certainly argue that a configure check would be nicer,
but Yanns' fix is atleast in line with the upstream code (it just
extends the existing glibc check in mbox.c).

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > clamav wants to use backtrace, and decides whether it can use it if it
 > detects a glibc >= 2.1.

 > But uClibc does impersonate a glibc >= 2.1, so clamav concludes it is
 > possible to use backtrace. So it includes execinfo.h, which is missing
 > in our default uClibc config file.

 > So, just extend the test so that backtrace support is disable on uClibc,
 > unless it has been configured with backtrace support.

 > A far better solution would be to add a ./configure check for backtrace,
 > but this patch is sufficient enough.

 > Fixes:
 >     http://autobuild.buildroot.net/results/cff/cffa32fcedda735983d4805d6d4fa77844539b10/
 >     http://autobuild.buildroot.net/results/e0a/e0a765a94a538b0b936ea512f7aba0264fac6309/
 >     ...

 > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Committed, thanks.

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Thomas, All,
 > On 2014-11-16 22:02 +0100, Thomas Petazzoni spake thusly:
 >> On Sun, 16 Nov 2014 18:21:04 +0100, Bernd Kuhls wrote:
 >> 
 >> > Please add the upstream bugtracker URL to your patch: 
 >> > https://bugzilla.clamav.net/show_bug.cgi?id=11170
 >> 
 >> I believe Yann's patch is not an appropriate upstream solution, and a
 >> configure.ac check should be added instead.

 > That's what I think, too. But see what Peter had to say about that (as
 > pointed out by Bernd):
 >     http://patchwork.ozlabs.org/patch/406336/

 > Now, upstream has both patches in their bug tracker: the original from
 > Bernd that adds a check in ./configure (well, rather in
 > m4/reorganization/headers.m4, but that gives a configure-time check),
 > and my patch, does just slightly expands the current test to recognise
 > uClibc.

Just to clarify - I don't object against a configure script, my comment
on http://patchwork.ozlabs.org/patch/406336/ was simply that the
existing HAVE_BACKTRACE check didn't work for uClibc and it made more
sense to fix that than add an additional HAVE_EXECINFO_H check.

 > But back to Buildroot: we need a fix before the release, and that patch
 > is what Peter asked for.

Yeah, and I've committed it. When upstream decides (and perhaps makes a
new release) we can update and get rid of the patch.