Linux 4.11 FTBFS on m68k

Linux 4.11 FTBFS on m68k

[John Paul Adrian Glaubitz]

Hi!

Just noticed that currently the 4.11 kernel fails to build from source
on m68k [1]:

  CC      arch/m68k/lib/ashldi3.o
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:18:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__mode'
 typedef   int SItype __mode(SI);
                      ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:19:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__mode'
 typedef unsigned int USItype __mode(SI);
                              ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:20:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__mode'
 typedef   int DItype __mode(DI);
                      ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:21:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__mode'
 typedef int word_type           __mode(__word__);
                                 ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:23:18: error: unknown type name 'SItype'
 struct DIstruct {SItype high, low;};
                  ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:28:3: error: unknown type name 'DItype'
   DItype ll;
   ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:31:1: error: unknown type name 'DItype'
 DItype
 ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:32:12: error: unknown type name 'DItype'
 __ashldi3 (DItype u, word_type b)
            ^~~~~~
/<<PKGBUILDDIR>>/arch/m68k/lib/ashldi3.c:32:22: error: unknown type name 'word_type'
 __ashldi3 (DItype u, word_type b)
                      ^~~~~~~~~
/<<PKGBUILDDIR>>/scripts/Makefile.build:299: recipe for target 'arch/m68k/lib/ashldi3.o' failed
make[6]: *** [arch/m68k/lib/ashldi3.o] Error 1
/<<PKGBUILDDIR>>/Makefile:1006: recipe for target 'arch/m68k/lib' failed
make[5]: *** [arch/m68k/lib] Error 2
make[5]: *** Waiting for unfinished jobs....

Might be something that is only triggered when building with newer gcc versions?
Looks like we need to add __attribute__ here, don't we?

Adrian

> [1] https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=4.11-1%7Eexp2&stamp=1493971608&raw=0

Re: Linux 4.11 FTBFS on m68k

[Andreas Schwab]

See commit 849de0cd2c.

Andreas.

Re: Linux 4.11 FTBFS on m68k

[Geert Uytterhoeven]

Hi Andreas,

On Sun, May 7, 2017 at 6:11 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> See commit 849de0cd2c.

And?

Is that commit known to break the build with gcc-6?
Is there a fix available?

Or am I misinterpreting your terse message?

Thanks!

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

Re: Linux 4.11 FTBFS on m68k

[Andreas Schwab]

On Mai 08 2017, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Andreas,
>
> On Sun, May 7, 2017 at 6:11 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> See commit 849de0cd2c.
>
> And?

"Looks like we need to add __attribute__ here, don't we?" is obviously
wrong.

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."

Re: Linux 4.11 FTBFS on m68k

[John Paul Adrian Glaubitz]

On 05/08/2017 07:32 PM, Andreas Schwab wrote:
> "Looks like we need to add __attribute__ here, don't we?" is obviously
> wrong.

I was just briefly glancing over it. After look at the commit you linked
and reading through the patch, I'm actually surprised that it doesn't work
because __mode() is defined as a macro in compiler-gcc.h to yield the
necessary __attribute__(__mode()) when gcc is used.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Linux 4.11 FTBFS on m68k

[John Paul Adrian Glaubitz]

On Sun, May 07, 2017 at 03:16:41PM +0200, John Paul Adrian Glaubitz wrote:
> Just noticed that currently the 4.11 kernel fails to build from source
> on m68k [1]:

Ok, this problem is actually Debian-specific. Debian's linux source
package contains a patch which removes the necessary #include
directive for <linux/compiler.h> [1].

I'll open a bug report.

Adrian

> [1] https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/bugfix/m68k/revert-m68k-move-exports-to-definitions.patch#n150

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Linux 4.11 FTBFS on m68k

[Michael Schmitz]

Hi Adrian,

this may be compiler version specific - I recall these functions were
used from the kernel source with gcc 3.3.6 or thereabouts (I had to add
__divdi3 five years ago for some driver that needed it and it wasn't
then provided by gcc for some reason). WIth gcc version 4, the need for
this hack was gone.

What version of gcc does Debian use for building their kernel packages?
What did you use?

Cheers,

	Michael


Am 12.05.2017 um 20:47 schrieb John Paul Adrian Glaubitz:
> On Sun, May 07, 2017 at 03:16:41PM +0200, John Paul Adrian Glaubitz wrote:
>> Just noticed that currently the 4.11 kernel fails to build from source
>> on m68k [1]:
> 
> Ok, this problem is actually Debian-specific. Debian's linux source
> package contains a patch which removes the necessary #include
> directive for <linux/compiler.h> [1].
> 
> I'll open a bug report.
> 
> Adrian
> 
>> [1] https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/bugfix/m68k/revert-m68k-move-exports-to-definitions.patch#n150
> 

Re: Linux 4.11 FTBFS on m68k

[Andreas Schwab]

On Mai 14 2017, Michael Schmitz <schmitzmic@gmail.com> wrote:

> this may be compiler version specific - I recall these functions were
> used from the kernel source with gcc 3.3.6 or thereabouts (I had to add
> __divdi3 five years ago for some driver that needed it and it wasn't
> then provided by gcc for some reason).

The kernel deliberately does not use libgcc, and it does not want a
64-bit devision on 32-bit archs.

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."

Re: Linux 4.11 FTBFS on m68k

[John Paul Adrian Glaubitz]

On 05/14/2017 05:11 AM, Michael Schmitz wrote:
> What version of gcc does Debian use for building their kernel packages?
> What did you use?

Debian uses gcc-6 for building the kernel which can also be seen from
the build log in question [1].

Adrian

> [1] https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=4.11-1%7Eexp2&stamp=1493971608&raw=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Linux 4.11 FTBFS on m68k

[Michael Schmitz]

Andreas,

On Sun, May 14, 2017 at 6:19 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Mai 14 2017, Michael Schmitz <schmitzmic@gmail.com> wrote:
>
>> this may be compiler version specific - I recall these functions were
>> used from the kernel source with gcc 3.3.6 or thereabouts (I had to add
>> __divdi3 five years ago for some driver that needed it and it wasn't
>> then provided by gcc for some reason).
>
> The kernel deliberately does not use libgcc, and it does not want a
> 64-bit devision on 32-bit archs.

At that time, it clearly didn't use libgcc. It's hard to be certain
but as far as I can reconstruct, the 64 bit division might have been
required for the isp116x-hcd USB driver (the ndelay used in there,
specifically). The current implementation clearny doesn't need 64 bit
division anymore.

Anyway, I missed the point about the __mode() macro no longer being
found - nothing to do with the arch/m68k/lib functions, nothing to see
here. Sorry about the noise.

Cheers,

  Michael