NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: install/48303: Linux cross build fails on ppc



The following reply was made to PR toolchain/48303; it has been noted by GNATS.

From: Justin Cormack <justin%specialbusservice.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
        netbsd-bugs%netbsd.org@localhost
Subject: Re: install/48303: Linux cross build fails on ppc
Date: Mon, 28 Oct 2013 13:07:39 +0000

 On Mon, Oct 28, 2013 at 1:00 PM, Alan Barrett <apb%cequrux.com@localhost> 
wrote:
 > The following reply was made to PR toolchain/48303; it has been noted by 
 > GNATS.
 >
 > From: Alan Barrett <apb%cequrux.com@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: install/48303: Linux cross build fails on ppc
 > Date: Mon, 28 Oct 2013 14:57:38 +0200
 >
 >  On Mon, 28 Oct 2013, Justin Cormack wrote:
 >  >I looked at where this was being redefined and it is in compat_defs.h
 >  >and the following patch fixes this issue, which makes it somewhat
 >  >simpler than I thought to fix. The only question is whether undefining
 >  >__unused is necessary on some other platform, in which case the
 >  >#define __unused could be wrapped eg in #ifndef __linux__ which should
 >  >be safe.
 >
 >  Is the Linux use of "__unused" as a struct member name something new?
 
 It is generally only found in non-x86 architectures, although it is
 also in some versions of struct stat on x86.
 
 >  Did you test a complete build with your patch?  The reason for the
 >  "#define __unused", which has been in compat_defs.h since 2006-10-12, is
 >  to deal with code that uses __unused in the NetBSD way, like
 >
 >         sometype varname __unused;
 >
 >  and if __unused is not defined then such code would cause a syntax
 >  error.  There seems to be such code in src/usr.sbin/makefs, which would
 >  be built from src/tools/makefs.  There might also be more uses of
 >  __unused in the tools build.
 
 Yes, apologies this patch will not work, the build eventually fails.
 
 I have filed a patch against glibc
 https://sourceware.org/ml/libc-alpha/2013-10/msg00870.html not sure if
 they will respond. It will still take a few years to filter to end
 user machines, so perhaps at least a note on the README in the compat
 directory could be helpful if there is really no way to fix this.
 
 Justin
 


Home | Main Index | Thread Index | Old Index