From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))
Date: Thu, 23 Oct 2014 15:57:44 +0200 [thread overview]
Message-ID: <3595731.DoMBPMAkQj@wuerfel> (raw)
In-Reply-To: <20141022223845.GE27405@n2100.arm.linux.org.uk>
On Wednesday 22 October 2014 23:38:45 Russell King - ARM Linux wrote:
> On Tue, Oct 21, 2014 at 10:44:12PM -0700, Olof's autobuilder wrote:
> > drivers/scsi/aic7xxx/aic7xxx_core.c:48:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic7xxx_93cx6.c:72:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic7xxx_pci.c:50:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic79xx_core.c:48:37: fatal error: dev/aic7xxx/aic79xx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic79xx_pci.c:48:37: fatal error: dev/aic7xxx/aic79xx_osm.h: No such file or directory
>
> I have a patch for the aic7xxx stuff to fix it for split builds, but
> whenever I've talked to jejb about it, the response is always negative,
> blaming my build environment as the cause of it because... apparently,
> no one else sees problems. Maybe it's time to gang up on jejb and
> convince him otherwise?
I think the problem here is
#ifdef __linux__
#include "aic7xxx_osm.h"
#include "aic7xxx_inline.h"
#include "aic7xxx_93cx6.h"
#else
#include <dev/aic7xxx/aic7xxx_osm.h>
#include <dev/aic7xxx/aic7xxx_inline.h>
#include <dev/aic7xxx/aic7xxx_93cx6.h>
#endif
so it should work as long as __linux__ is set. I remember having discussed similar
issues in the past, but don't remember the exact outcome. I would have expected
normal compilers to set __linux__, but we also have hacks in various places
to work around toolchains that don't
$ git grep __linux__
Makefile:CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
arch/arc/Makefile:cflags-y += -mA7 -fno-common -pipe -fno-builtin -D__linux__
arch/avr32/Makefile:KBUILD_CFLAGS += -pipe -fno-builtin -mno-pic -D__linux__
arch/hexagon/Makefile:KBUILD_CFLAGS += -ffixed-$(TIR_NAME) -DTHREADINFO_REG=$(TIR_NAME) -D__linux__
arch/mips/include/uapi/asm/sgidefs.h:#ifndef __linux__
arch/openrisc/Makefile:KBUILD_CFLAGS += -pipe -ffixed-r10 -D__linux__
arch/score/Makefile: -D__linux__ -ffunction-sections -ffreestanding
arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__
drivers/gpu/drm/radeon/radeon_cp.c:#ifdef __linux__
drivers/gpu/drm/radeon/radeon_cp.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7770.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic79xx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_pci.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_93cx6.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_pci.c:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm.h:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_gram.y:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_scan.l:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__
drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__))
fs/ext4/ext4.h:#if defined(__KERNEL__) || defined(__linux__)
fs/ext4/ext4.h:#endif /* defined(__KERNEL__) || defined(__linux__) */
include/acpi/platform/acenv.h:#if defined(_LINUX) || defined(__linux__)
include/acpi/platform/acenvex.h:#if defined(_LINUX) || defined(__linux__)
include/linux/coda.h:#if defined(__linux__)
include/uapi/drm/drm.h:#if defined(__KERNEL__) || defined(__linux__)
include/uapi/linux/coda.h:#if defined(__linux__)
So five parts of the kernel check for __linux__, all of them are shared
with another OS, or at least used to be: drm, coda, ext4, acpi and aic7xxx.
The check is to determine whether we are building for Linux or not.
Some of them check for __KERNEL__ or __linux__, and we know that __KERNEL__
is always set when building the Linux kernel, and __linux__ is always set
when building Linux user space.
Some architectures evidently have workarounds to define __linux__ even
when building with other compilers.
See also https://bugs.launchpad.net/linaro-android/+bug/868550
> So, size_t is typedef'd as "unsigned int" - and indeed, the compiler thinks
> that size_t is "unsigned int". But it doesn't seem to like the use of the
> 'z' flag in the printf format string with size_t.
>
> Any ideas what's going on here? Does gcc 4.9 stddef.h define size_t
> differently?
This may be a related issue to the first one. Maybe the linux toolchain uses
a different type from the generic toolchain.
Arnd
next prev parent reply other threads:[~2014-10-23 13:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5447442c.a9ca440a.2060.5e09@mx.google.com>
2014-10-22 22:38 ` gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022)) Russell King - ARM Linux
2014-10-23 13:57 ` Arnd Bergmann [this message]
2014-10-23 14:14 ` Russell King - ARM Linux
2014-10-23 15:33 ` Arnd Bergmann
2014-10-23 16:12 ` Russell King - ARM Linux
2014-10-23 20:31 ` Arnd Bergmann
2014-10-23 20:33 ` Olof Johansson
2014-10-24 9:13 ` Arnd Bergmann
2014-10-24 9:34 ` Arnd Bergmann
2014-10-24 9:44 ` Russell King - ARM Linux
2014-10-24 10:27 ` Arnd Bergmann
2014-10-24 18:25 ` Segher Boessenkool
2014-10-24 18:33 ` Russell King - ARM Linux
2014-10-24 21:47 ` Olof Johansson
2014-11-11 21:32 ` Arnd Bergmann
2014-11-12 1:34 ` Olof Johansson
2014-11-12 10:48 ` Russell King - ARM Linux
2014-11-13 14:19 ` Segher Boessenkool
2014-11-13 14:30 ` Arnd Bergmann
2014-10-23 22:03 ` Ard Biesheuvel
2014-10-23 22:26 ` Russell King - ARM Linux
2014-10-24 21:47 ` Olof Johansson
2014-10-24 21:56 ` Russell King - ARM Linux
2014-10-24 22:22 ` Olof Johansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3595731.DoMBPMAkQj@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).