Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1457609 > unrolled thread

Re: Build regressions/improvements in v4.8-rc1

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Build regressions/improvements in v4.8-rc1 Geert Uytterhoeven <geert@linux-m68k.org> - 2016-08-08 10:40 +0200
    Re: Build regressions/improvements in v4.8-rc1 Rich Felker <dalias@libc.org> - 2016-08-08 16:40 +0200
      Re: Build regressions/improvements in v4.8-rc1 Geert Uytterhoeven <geert@linux-m68k.org> - 2016-08-08 17:50 +0200
        Re: Build regressions/improvements in v4.8-rc1 Rich Felker <dalias@libc.org> - 2016-08-08 18:30 +0200
          Re: Build regressions/improvements in v4.8-rc1 Andreas Schwab <schwab@linux-m68k.org> - 2016-08-08 19:10 +0200
            Re: Build regressions/improvements in v4.8-rc1 Geert Uytterhoeven <geert@linux-m68k.org> - 2016-08-08 22:10 +0200
    Re: Build regressions/improvements in v4.8-rc1 Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2016-08-08 18:30 +0200

#1457609 — Re: Build regressions/improvements in v4.8-rc1

On Mon, Aug 8, 2016 at 10:32 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.8-rc1[1] compared to v4.7[2].
>
> Summarized:
>   - build errors: +8/-12

>   + /home/kisskb/slave/src/arch/arm/kernel/setup.c: error: 'SECTION_SIZE' undeclared (first use in this function):  => 1003:25

arm-randconfig

>   + error: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!:  => N/A

bfin/CM-BF548_defconfig

>   + error: /home/kisskb/slave/src/drivers/block/loop.c: undefined reference to `__ucmpdi2':  => .text+0x3aaee), .text+0x2ee10), .text+0x2ee1c)
>   + error: /home/kisskb/slave/src/drivers/scsi/sd.c: undefined reference to `__ucmpdi2':  => .text+0x36cb8), .text+0x3865c)

Various blackfin

>   + error: No rule to make target arch/sh/boot/dts/.dtb.o:  => N/A

sh-allyesconfig, sh-allmodconfig

>   + {standard input}: Error: Instruction with long immediate data in delay slot:  => 18728

arcv2/axs103_smp_defconfig

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [next] | [standalone]

#1457837

On Mon, Aug 08, 2016 at 10:38:07AM +0200, Geert Uytterhoeven wrote:
> On Mon, Aug 8, 2016 at 10:32 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v4.8-rc1[1] compared to v4.7[2].
> >
> > Summarized:
> >   - build errors: +8/-12
> 
> >   + /home/kisskb/slave/src/arch/arm/kernel/setup.c: error: 'SECTION_SIZE' undeclared (first use in this function):  => 1003:25
> 
> arm-randconfig
> 
> >   + error: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!:  => N/A
> 
> bfin/CM-BF548_defconfig
> 
> >   + error: /home/kisskb/slave/src/drivers/block/loop.c: undefined reference to `__ucmpdi2':  => .text+0x3aaee), .text+0x2ee10), .text+0x2ee1c)
> >   + error: /home/kisskb/slave/src/drivers/scsi/sd.c: undefined reference to `__ucmpdi2':  => .text+0x36cb8), .text+0x3865c)
> 
> Various blackfin
> 
> >   + error: No rule to make target arch/sh/boot/dts/.dtb.o:  => N/A
> 
> sh-allyesconfig, sh-allmodconfig

I saw this. Is there any canonical way I should fix this? The problem
is that there's no default for the DTS name, but I'm not sure there
should be a default. Getting a hard-coded DTB for a particular board
when you do allyesconfig seems like a worse UX than getting a build
failure.

Rich

[toc] | [prev] | [next] | [standalone]

#1457867

Hi Rich,

On Mon, Aug 8, 2016 at 4:31 PM, Rich Felker <dalias@libc.org> wrote:
> On Mon, Aug 08, 2016 at 10:38:07AM +0200, Geert Uytterhoeven wrote:
>> On Mon, Aug 8, 2016 at 10:32 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> >   + error: No rule to make target arch/sh/boot/dts/.dtb.o:  => N/A
>>
>> sh-allyesconfig, sh-allmodconfig
>
> I saw this. Is there any canonical way I should fix this? The problem
> is that there's no default for the DTS name, but I'm not sure there
> should be a default. Getting a hard-coded DTB for a particular board
> when you do allyesconfig seems like a worse UX than getting a build
> failure.

Do you have a way to pass a DTB from the bootloader, like most other
architectures support?
If yes, can't you remove the dependency on a builtin DTB?
Allowing to build allmodconfig/allyesconfig helps a lot for build coverage.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1457897

On Mon, Aug 08, 2016 at 05:46:33PM +0200, Geert Uytterhoeven wrote:
> Hi Rich,
> 
> On Mon, Aug 8, 2016 at 4:31 PM, Rich Felker <dalias@libc.org> wrote:
> > On Mon, Aug 08, 2016 at 10:38:07AM +0200, Geert Uytterhoeven wrote:
> >> On Mon, Aug 8, 2016 at 10:32 AM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> >   + error: No rule to make target arch/sh/boot/dts/.dtb.o:  => N/A
> >>
> >> sh-allyesconfig, sh-allmodconfig
> >
> > I saw this. Is there any canonical way I should fix this? The problem
> > is that there's no default for the DTS name, but I'm not sure there
> > should be a default. Getting a hard-coded DTB for a particular board
> > when you do allyesconfig seems like a worse UX than getting a build
> > failure.
> 
> Do you have a way to pass a DTB from the bootloader, like most other
> architectures support?

Yes, and that's the intended use, but I added support for builtin DTB
for use with systems where it's hard to replace the bootloader with
one that can pass a DTB.

> If yes, can't you remove the dependency on a builtin DTB?
> Allowing to build allmodconfig/allyesconfig helps a lot for build coverage.

Users should leave builtin-DTB off, but allyesconfig turns it on.

Rich

[toc] | [prev] | [next] | [standalone]

#1457925

On Mo, Aug 08 2016, Rich Felker <dalias@libc.org> wrote:

> Users should leave builtin-DTB off, but allyesconfig turns it on.

Perhaps you could inverse the meaning of the config so that y means
builtin-DTB off?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[toc] | [prev] | [next] | [standalone]

#1458208

On Mon, Aug 8, 2016 at 7:02 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Mo, Aug 08 2016, Rich Felker <dalias@libc.org> wrote:
>
>> Users should leave builtin-DTB off, but allyesconfig turns it on.
>
> Perhaps you could inverse the meaning of the config so that y means
> builtin-DTB off?

That's one option,

The other one is to ignore it if CONFIG_BUILTIN_DTB_SOURCE is an
empty string. A bit similar to CONFIG_CMDLINE on ARM.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1457898

Hi Geert,

On 08/08/2016 01:38 AM, Geert Uytterhoeven wrote:
>>   + {standard input}: Error: Instruction with long immediate data in delay slot:  => 18728
> arcv2/axs103_smp_defconfig

What build service/farm does this use. Recently Guenter ran into this too and
updated his toolchain to work around the gcc bug.

-Vineet

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web