[Buildroot] [PATCH 1/1] packages/btrfs-progs: fix build issues under musl

[Buildroot] [PATCH 1/1] packages/btrfs-progs: fix build issues under musl

[Brendan Heading]

Fixes http://autobuild.buildroot.net/results/b97/b97f1e9cd459da96e3e1680bb7c43d8103ab12c2/

Caused by assumptions around __GLIBC__ and header inclusion.

Signed-off-by: Brendan Heading <brendanheading@gmail.com>
---
 ...s-compilation-errors-when-using-musl-libc.patch | 91 ++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 package/btrfs-progs/0001-btrfs-progs-compilation-errors-when-using-musl-libc.patch

diff --git a/package/btrfs-progs/0001-btrfs-progs-compilation-errors-when-using-musl-libc.patch b/package/btrfs-progs/0001-btrfs-progs-compilation-errors-when-using-musl-libc.patch
new file mode 100644
index 0000000..dde1851
--- /dev/null
+++ b/package/btrfs-progs/0001-btrfs-progs-compilation-errors-when-using-musl-libc.patch
@@ -0,0 +1,91 @@
+From 8905b451014fce570984335f153f3977e94f0115 Mon Sep 17 00:00:00 2001
+From: Brendan Heading <brendanheading@gmail.com>
+Date: Wed, 29 Jul 2015 19:27:26 +0100
+Subject: [PATCH 1/1] btrfs-progs: compilation errors when using musl libc
+
+- limits.h must be included to pick up PATH_MAX.
+- remove double declaration of BTRFS_DISABLE_BACKTRACE
+
+kerncompat.h assumed that if __GLIBC__ was not defined,
+it could safely define BTRFS_DISABLE_BACKTRACE, however this can be
+defined by the configure script. Added a check to ensure it is not
+defined first.
+
+Upstream-status: submitted
+
+See : http://thread.gmane.org/gmane.comp.file-systems.btrfs/46771
+
+Signed-off-by: Brendan Heading <brendanheading@gmail.com>
+---
+ cmds-inspect.c | 1 +
+ cmds-receive.c | 1 +
+ cmds-scrub.c   | 1 +
+ cmds-send.c    | 1 +
+ kerncompat.h   | 2 ++
+ 5 files changed, 6 insertions(+)
+
+diff --git a/cmds-inspect.c b/cmds-inspect.c
+index 71451fe..9712581 100644
+--- a/cmds-inspect.c
++++ b/cmds-inspect.c
+@@ -20,6 +20,7 @@
+ #include <stdint.h>
+ #include <sys/ioctl.h>
+ #include <errno.h>
++#include <limits.h>
+ 
+ #include "kerncompat.h"
+ #include "ioctl.h"
+diff --git a/cmds-receive.c b/cmds-receive.c
+index 071bea9..d4b3103 100644
+--- a/cmds-receive.c
++++ b/cmds-receive.c
+@@ -28,6 +28,7 @@
+ #include <wait.h>
+ #include <assert.h>
+ #include <getopt.h>
++#include <limits.h>
+ 
+ #include <sys/stat.h>
+ #include <sys/types.h>
+diff --git a/cmds-scrub.c b/cmds-scrub.c
+index b7aa809..5a85dc4 100644
+--- a/cmds-scrub.c
++++ b/cmds-scrub.c
+@@ -34,6 +34,7 @@
+ #include <ctype.h>
+ #include <signal.h>
+ #include <stdarg.h>
++#include <limits.h>
+ 
+ #include "ctree.h"
+ #include "ioctl.h"
+diff --git a/cmds-send.c b/cmds-send.c
+index 20bba18..a0b7f95 100644
+--- a/cmds-send.c
++++ b/cmds-send.c
+@@ -33,6 +33,7 @@
+ #include <assert.h>
+ #include <getopt.h>
+ #include <uuid/uuid.h>
++#include <limits.h>
+ 
+ #include "ctree.h"
+ #include "ioctl.h"
+diff --git a/kerncompat.h b/kerncompat.h
+index 5d92856..7c627ba 100644
+--- a/kerncompat.h
++++ b/kerncompat.h
+@@ -33,7 +33,9 @@
+ #include <features.h>
+ 
+ #ifndef __GLIBC__
++#ifndef BTRFS_DISABLE_BACKTRACE
+ #define BTRFS_DISABLE_BACKTRACE
++#endif
+ #define __always_inline __inline __attribute__ ((__always_inline__))
+ #endif
+ 
+-- 
+2.4.3
+
-- 
2.4.3

[Buildroot] [PATCH 1/1] packages/btrfs-progs: fix build issues under musl

[Thomas Petazzoni]

Dear Brendan Heading,

On Wed, 29 Jul 2015 19:50:15 +0100, Brendan Heading wrote:

> +diff --git a/kerncompat.h b/kerncompat.h
> +index 5d92856..7c627ba 100644
> +--- a/kerncompat.h
> ++++ b/kerncompat.h
> +@@ -33,7 +33,9 @@
> + #include <features.h>
> + 
> + #ifndef __GLIBC__
> ++#ifndef BTRFS_DISABLE_BACKTRACE
> + #define BTRFS_DISABLE_BACKTRACE
> ++#endif

While this is a quick hack that works, I think it's really nothing more
than a hack. I've implemented what I believe is a better solution, can
you look at:

	https://github.com/tpetazzoni/btrfs-progs/commits/configure-improvements

(last two commits)

Basically, this proposal uses configure.ac properly to detect backtrace
support.

Can you check if that continues to work fine with glibc and musl, and
if so, submit the patches upstream?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] packages/btrfs-progs: fix build issues under musl

[Brendan Heading]

> Can you check if that continues to work fine with glibc and musl, and
> if so, submit the patches upstream?
>
> Thanks a lot!

Sure. I will make a buildroot patch too.

Brendan

[Buildroot] [PATCH 1/1] packages/btrfs-progs: fix build issues under musl

[Brendan Heading]

> While this is a quick hack that works, I think it's really nothing more
> than a hack. I've implemented what I believe is a better solution, can
> you look at:
>
>         https://github.com/tpetazzoni/btrfs-progs/commits/configure-improvements
[..]
> Can you check if that continues to work fine with glibc and musl, and
> if so, submit the patches upstream?

Thomas,

Unfortunately things moved a bit quickly - I'd submitted my patch to
btrfs-progs yesterday and it was accepted earlier this morning before
I had a chance to tell them about your more comprehensive approach.

Your inline patch had one small typo:
=============================

--- a/kerncompat.h
+++ b/kerncompat.h
@@ -32,7 +32,7 @@

 #include <features.h>

-#ifdef HAVE_ALWAYS_INLINE
+#ifndef HAVE_ALWAYS_INLINE
 #define __always_inline __inline __attribute__ ((__always_inline__))
 #endif
=============================

Also, the build still requires that limits.h is included, but that was
not in the scope of what you were doing.

Therefore I propose to add three patches to buildroot - your two (with
the #ifndef fixed), plus one for limits.h.

For the upstream, I will modify your patch slightly so that it reverts
the relevant three-line part of my previous patch. OK ?

regards

Brendan

[Buildroot] [PATCH 1/1] packages/btrfs-progs: fix build issues under musl

[Thomas Petazzoni]

Dear Brendan Heading,

On Thu, 30 Jul 2015 15:16:04 +0100, Brendan Heading wrote:

> Unfortunately things moved a bit quickly - I'd submitted my patch to
> btrfs-progs yesterday and it was accepted earlier this morning before
> I had a chance to tell them about your more comprehensive approach.
> 
> Your inline patch had one small typo:
> =============================
> 
> --- a/kerncompat.h
> +++ b/kerncompat.h
> @@ -32,7 +32,7 @@
> 
>  #include <features.h>
> 
> -#ifdef HAVE_ALWAYS_INLINE
> +#ifndef HAVE_ALWAYS_INLINE
>  #define __always_inline __inline __attribute__ ((__always_inline__))

Humm, in fact my patch is wrong. So what they were doing is:

 #ifndef __GLIBC__
 #define __always_inline __inline __attribute__ ((__always_inline__))
 #endif

So in fact they are not testing that __always_inline__ is a valid gcc
function attribute.

They are defining __always_inline as a shortcut for marking a function
as always inline. This shortcut is defined by glibc, but not by other C
libraries, so they are doing it manually.

So, I think my patch should be adapted. You need to:

 * Remove the m4/ax_gcc_func_attribute.m4 file, revert my .gitignore
   change and remove the added AC_CONFIG_MACRO_DIR([m4]).

 * Add AC_CHECK_DECLS([__always_inline]) in configure.ac, and do
   #ifndef HAVE_DECL___ALWAYS_INLINE in kerncompat.h.

It will in fact make the patch a lot simpler, which is good.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] packages/btrfs-progs: fix build issues under musl

[Brendan Heading]

> So, I think my patch should be adapted. You need to:
>
>  * Remove the m4/ax_gcc_func_attribute.m4 file, revert my .gitignore
>    change and remove the added AC_CONFIG_MACRO_DIR([m4]).
>
>  * Add AC_CHECK_DECLS([__always_inline]) in configure.ac, and do
>    #ifndef HAVE_DECL___ALWAYS_INLINE in kerncompat.h.
>
> It will in fact make the patch a lot simpler, which is good.

Thomas,

Tested with both the autobuild config (musl) and Linaro 2014.9, builds
fine. Forwarding the buildroot patches now, then I'll look at
submitting them upstream.

regards

Brendan