| Message ID | 0cb3afed06c399b9e7d721aa3dafe6ba0eb7e5e5.1478457789.git.baruch@tkos.co.il |
|---|---|
| State | Changes Requested |
| Headers | show |
On 06-11-16 19:43, Baruch Siach wrote: > Rick Felker suggested[1] this hack as a workaround to musl libc conflict with > kernel headers. Upstream musl still evaluates[2] a permanent solution. Add an explanation of what the hack does. Actually, quoting Rick's fully explanation is probably the best thing to do. > > With this in place we can revert (at least) commits a167081c5d (bridge-utils: > fix build with musl) and e74d4fc4932 (norm: add patch to fix musl build). > > [1] http://www.openwall.com/lists/musl/2015/10/08/2 > [2] http://www.openwall.com/lists/musl/2016/10/18/1 > > Signed-off-by: Baruch Siach <baruch@tkos.co.il> > --- > toolchain/toolchain/toolchain.mk | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk > index c22713bfe349..d317e917d032 100644 > --- a/toolchain/toolchain/toolchain.mk > +++ b/toolchain/toolchain/toolchain.mk > @@ -12,6 +12,20 @@ endif > > TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO > > +# Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc > +# headers and kernel headers. This is a temporary measure until musl finds a > +# better solution. > +# > +# [1] http://www.openwall.com/lists/musl/2015/10/08/2 > +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y) > +define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK > + $(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \ > + $(STAGING_DIR)/usr/include/linux/libc-compat.h > +endef > +TOOLCHAIN_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK > +TOOLCHAIN_INSTALL_STAGING = YES TOOLCHAIN_POST_INSTALL_STAGING is not ideal because it normally doesn't install to staging. Can it be moved to musl-compat-headers? It's a bit of work, because it requires first to move the musl-compat-headers dependency from musl and toolchain-external to toolchain itself, and then to add dependencies in musl-compat-headers on linux-headers resp. toolchain-external depending on which of the two is selected. But I think it's cleaner in the end. OTOH this is a hack which can hopefully removed at some point so maybe it doesn't have to be so clean. Regards, Arnout > +endif > + > $(eval $(virtual-package)) > > toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake >
Hi Arnout, On Wed, Nov 09, 2016 at 12:04:37AM +0100, Arnout Vandecappelle wrote: > On 06-11-16 19:43, Baruch Siach wrote: > > Rick Felker suggested[1] this hack as a workaround to musl libc conflict with > > kernel headers. Upstream musl still evaluates[2] a permanent solution. > > Add an explanation of what the hack does. Actually, quoting Rick's fully > explanation is probably the best thing to do. Will do. [...] > > diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk > > index c22713bfe349..d317e917d032 100644 > > --- a/toolchain/toolchain/toolchain.mk > > +++ b/toolchain/toolchain/toolchain.mk > > @@ -12,6 +12,20 @@ endif > > > > TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO > > > > +# Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc > > +# headers and kernel headers. This is a temporary measure until musl finds a > > +# better solution. > > +# > > +# [1] http://www.openwall.com/lists/musl/2015/10/08/2 > > +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y) > > +define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK > > + $(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \ > > + $(STAGING_DIR)/usr/include/linux/libc-compat.h > > +endef > > +TOOLCHAIN_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK > > +TOOLCHAIN_INSTALL_STAGING = YES > > TOOLCHAIN_POST_INSTALL_STAGING is not ideal because it normally doesn't install > to staging. Can it be moved to musl-compat-headers? It's a bit of work, because > it requires first to move the musl-compat-headers dependency from musl and > toolchain-external to toolchain itself, and then to add dependencies in > musl-compat-headers on linux-headers resp. toolchain-external depending on which > of the two is selected. But I think it's cleaner in the end. I think your suggestion is way too complex for this ugly hack. It spreads the ugliness all over the place instead of keeping it in its corner. > OTOH this is a hack which can hopefully removed at some point so maybe it > doesn't have to be so clean. I agree. baruch
diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk index c22713bfe349..d317e917d032 100644 --- a/toolchain/toolchain/toolchain.mk +++ b/toolchain/toolchain/toolchain.mk @@ -12,6 +12,20 @@ endif TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO +# Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc +# headers and kernel headers. This is a temporary measure until musl finds a +# better solution. +# +# [1] http://www.openwall.com/lists/musl/2015/10/08/2 +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y) +define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK + $(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \ + $(STAGING_DIR)/usr/include/linux/libc-compat.h +endef +TOOLCHAIN_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK +TOOLCHAIN_INSTALL_STAGING = YES +endif + $(eval $(virtual-package)) toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
Rick Felker suggested[1] this hack as a workaround to musl libc conflict with kernel headers. Upstream musl still evaluates[2] a permanent solution. With this in place we can revert (at least) commits a167081c5d (bridge-utils: fix build with musl) and e74d4fc4932 (norm: add patch to fix musl build). [1] http://www.openwall.com/lists/musl/2015/10/08/2 [2] http://www.openwall.com/lists/musl/2016/10/18/1 Signed-off-by: Baruch Siach <baruch@tkos.co.il> --- toolchain/toolchain/toolchain.mk | 14 ++++++++++++++ 1 file changed, 14 insertions(+)