From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25560 invoked by alias); 12 Jan 2014 11:10:52 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18323 Received: (qmail 16982 invoked from network); 12 Jan 2014 11:10:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 Message-ID: <52D2780C.8090705@bernd-steinhauser.de> Date: Sun, 12 Jan 2014 12:10:04 +0100 From: Bernd Steinhauser User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: zsh-users@zsh.org Subject: Re: Compilation failure for zsh-5.0.5 References: <52D06EA2.1080100@bernd-steinhauser.de> <140110155525.ZM21199@torch.brasslantern.com> <52D1079D.40007@bernd-steinhauser.de> <140111100751.ZM14480@torch.brasslantern.com> In-Reply-To: <140111100751.ZM14480@torch.brasslantern.com> Content-Type: multipart/mixed; boundary="------------060702010104040905040404" --------------060702010104040905040404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/01/14 19:07, Bart Schaefer wrote: > On Jan 11, 9:58am, Bernd Steinhauser wrote: > } > } > That error is coming from a system-level header file ... we need to know > } > not just the glibc version, but the compiler and also operating system > } > > } Operating System is Exherbo Linux with kernel 3.13.0-rc7 running on amd64: > > www.exherbo.org: > > "We need the freedom to break things when necessary." > > Looks like perhaps they did? Not this time. ;) Apart from that, we do have almost no distribution-specific breakage, as we try to stick to upstream as close as possible when packaging. > Anybody out there got an install of this they can test with? There's > no prebuilt image or "live cd" I can find except for a KVM virtual > guest (and I don't have KVM). Maybe I'm just not looking hard enough. Apparently, it seems to be bug in glibc, which is fixed in 2.18. So the proper solution is to upgrade to that or patch glibc if a patch is available (which other distributions might have done, so they don't see that problem). The patch below after the hint of Jun Takimoto is a workaround (had to move both includes), but the root of the problem seems to be in glibc. So it shouldn't be necessary to patch zsh. Thank for the help. --------------060702010104040905040404 Content-Type: text/x-patch; name="0001-Move-includes-to-fix-compilation-failure.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Move-includes-to-fix-compilation-failure.patch" >>From 22fdc8c0bf640557ae06dd609fd3ca0a65176947 Mon Sep 17 00:00:00 2001 From: Bernd Steinhauser Date: Sun, 12 Jan 2014 12:00:22 +0100 Subject: [PATCH] Move includes to fix compilation failure. --- Src/Modules/attr.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Src/Modules/attr.c b/Src/Modules/attr.c index 6e08b10..b57874e 100644 --- a/Src/Modules/attr.c +++ b/Src/Modules/attr.c @@ -27,12 +27,13 @@ * */ -#include "attr.mdh" -#include "attr.pro" #include #include +#include "attr.mdh" +#include "attr.pro" + static ssize_t xgetxattr(const char *path, const char *name, void *value, size_t size, int symlink) { -- 1.8.5.2 --------------060702010104040905040404--