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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.