[Buildroot] [PATCH] kmsxx: not available on m68k

[Buildroot] [PATCH] kmsxx: not available on m68k

[Peter Korsgaard]

Fixes:
http://autobuild.buildroot.net/results/273/2738e5fd446467b105f6dcca391500e3734e5a9b/
http://autobuild.buildroot.net/results/7eb/7ebaa00b2d14131fadd15df6db32632828c1de33/
http://autobuild.buildroot.net/results/42c/42c2aa4b58de3ab84a27f53a696fa60d087c178b/

GCC dies with an internal compiler error when building kmsxx on m68k, so disable it.

These autobuilder issues are with a 2016.11 toolchain (gcc 5.x), but also
verified with gcc 6.3.0 / binutils 2.27.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 package/kmsxx/Config.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/kmsxx/Config.in b/package/kmsxx/Config.in
index 1d174c18b..3750897bb 100644
--- a/package/kmsxx/Config.in
+++ b/package/kmsxx/Config.in
@@ -4,6 +4,7 @@ config BR2_PACKAGE_KMSXX
 	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
+	depends on !BR2_m68k # gcc ice
 	select BR2_PACKAGE_LIBDRM
 	help
 	  libkms++ is a C++11 library for kernel mode setting.
@@ -24,3 +25,4 @@ endif
 comment "kms++ needs a toolchain w/ threads, C++, gcc >= 4.8, headers >= 3.8"
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP || \
 		!BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 || !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
+	depends on !BR2_m68k
-- 
2.11.0

[Buildroot] [PATCH] kmsxx: not available on m68k

[Thomas Petazzoni]

Hello,

On Mon, 13 Feb 2017 10:35:02 +0100, Peter Korsgaard wrote:

> diff --git a/package/kmsxx/Config.in b/package/kmsxx/Config.in
> index 1d174c18b..3750897bb 100644
> --- a/package/kmsxx/Config.in
> +++ b/package/kmsxx/Config.in
> @@ -4,6 +4,7 @@ config BR2_PACKAGE_KMSXX
>  	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
>  	depends on BR2_INSTALL_LIBSTDCPP
>  	depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
> +	depends on !BR2_m68k # gcc ice

As usual, I really prefer if we report the bug to gcc upstream, and
then do a depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_xyz. Otherwise, it's
really tricky to keep track of when this or that issue gets resolved
and when we can re-enable m68k.

CC'ing Waldemar on this.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] kmsxx: not available on m68k

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Mon, 13 Feb 2017 10:35:02 +0100, Peter Korsgaard wrote:

 >> diff --git a/package/kmsxx/Config.in b/package/kmsxx/Config.in
 >> index 1d174c18b..3750897bb 100644
 >> --- a/package/kmsxx/Config.in
 >> +++ b/package/kmsxx/Config.in
 >> @@ -4,6 +4,7 @@ config BR2_PACKAGE_KMSXX
 >> depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
 >> depends on BR2_INSTALL_LIBSTDCPP
 >> depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
 >> +	depends on !BR2_m68k # gcc ice

 > As usual, I really prefer if we report the bug to gcc upstream, and
 > then do a depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_xyz. Otherwise, it's
 > really tricky to keep track of when this or that issue gets resolved
 > and when we can re-enable m68k.

 > CC'ing Waldemar on this.

That's also fine by me if somebody wants to do that. I personally don't
know/care enough about m68k, and it has been failing since October
without anything happening, so I think we should disable it.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] kmsxx: not available on m68k

[Waldemar Brodkorb]

Hi Peter,
Peter Korsgaard wrote,

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
>  > Hello,
>  > On Mon, 13 Feb 2017 10:35:02 +0100, Peter Korsgaard wrote:
> 
>  >> diff --git a/package/kmsxx/Config.in b/package/kmsxx/Config.in
>  >> index 1d174c18b..3750897bb 100644
>  >> --- a/package/kmsxx/Config.in
>  >> +++ b/package/kmsxx/Config.in
>  >> @@ -4,6 +4,7 @@ config BR2_PACKAGE_KMSXX
>  >> depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
>  >> depends on BR2_INSTALL_LIBSTDCPP
>  >> depends on BR2_TOOLCHAIN_HAS_THREADS # libdrm
>  >> +	depends on !BR2_m68k # gcc ice
> 
>  > As usual, I really prefer if we report the bug to gcc upstream, and
>  > then do a depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_xyz. Otherwise, it's
>  > really tricky to keep track of when this or that issue gets resolved
>  > and when we can re-enable m68k.
> 
>  > CC'ing Waldemar on this.
> 
> That's also fine by me if somebody wants to do that. I personally don't
> know/care enough about m68k, and it has been failing since October
> without anything happening, so I think we should disable it.

It is not that nothing happened.
I think this would be solved by my following patch:
http://buildroot-busybox.2317881.n4.nabble.com/PATCH-m68k-add-special-gcc-flag-to-avoid-ICE-for-coldfire-td151151.html

Did you had a chance to discuss the required changes with Arnout in
the last developer meeting?

best regards
 Waldemar

[Buildroot] [PATCH] kmsxx: not available on m68k

[Peter Korsgaard]

>>>>> "Waldemar" == Waldemar Brodkorb <wbx@openadk.org> writes:

Hi,

 >> That's also fine by me if somebody wants to do that. I personally don't
 >> know/care enough about m68k, and it has been failing since October
 >> without anything happening, so I think we should disable it.

 > It is not that nothing happened.
 > I think this would be solved by my following patch:
 > http://buildroot-busybox.2317881.n4.nabble.com/PATCH-m68k-add-special-gcc-flag-to-avoid-ICE-for-coldfire-td151151.html

Sorry, I forgot about the relation between this build issue and the
"magic" compiler flag.

 > Did you had a chance to discuss the required changes with Arnout in
 > the last developer meeting?

I could only join from Monday evening, but I don't think so.

We are again past rc1, so I think the safest approach for 2017.02 is to
not add it to the wrapper, but instead explicitly pass it in kmsxx.mk
(and any other package with the same problem). From my IRC history this
also seems to be what you discussed with Thomas yesterday.

Will you send patches to do this?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] kmsxx: not available on m68k

[Thomas Petazzoni]

Hello,

On Tue, 14 Feb 2017 11:15:15 +0100, Peter Korsgaard wrote:

> We are again past rc1, so I think the safest approach for 2017.02 is to
> not add it to the wrapper, but instead explicitly pass it in kmsxx.mk
> (and any other package with the same problem). From my IRC history this
> also seems to be what you discussed with Thomas yesterday.

In addition, only 3 packages need it for the moment according to
Waldemar, so I think for now a per-package fix is better. We'll see
later if this needs to be generalized and put into the wrapper if
really a large number of packages are affected.

Has this issue been reported upstream?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] kmsxx: not available on m68k

[Waldemar Brodkorb]

Hi Peter,
Peter Korsgaard wrote,

> >>>>> "Waldemar" == Waldemar Brodkorb <wbx@openadk.org> writes:
> 
> Hi,
> 
>  >> That's also fine by me if somebody wants to do that. I personally don't
>  >> know/care enough about m68k, and it has been failing since October
>  >> without anything happening, so I think we should disable it.
> 
>  > It is not that nothing happened.
>  > I think this would be solved by my following patch:
>  > http://buildroot-busybox.2317881.n4.nabble.com/PATCH-m68k-add-special-gcc-flag-to-avoid-ICE-for-coldfire-td151151.html
> 
> Sorry, I forgot about the relation between this build issue and the
> "magic" compiler flag.
> 
>  > Did you had a chance to discuss the required changes with Arnout in
>  > the last developer meeting?
> 
> I could only join from Monday evening, but I don't think so.
> 
> We are again past rc1, so I think the safest approach for 2017.02 is to
> not add it to the wrapper, but instead explicitly pass it in kmsxx.mk
> (and any other package with the same problem). From my IRC history this
> also seems to be what you discussed with Thomas yesterday.
> 
> Will you send patches to do this?

I can try. But now I am back to my original problem, how do I
overwrite CFLAGS/CXXFLAGS correctly for a single package build with
cmake?

Any examples in the tree?

I think that was the reason we tried to add it globally in the
wrapper :/

best regards
 Waldemar

[Buildroot] [PATCH] kmsxx: not available on m68k

[Thomas Petazzoni]

Hello,

On Tue, 14 Feb 2017 12:42:04 +0100, Waldemar Brodkorb wrote:

> I can try. But now I am back to my original problem, how do I
> overwrite CFLAGS/CXXFLAGS correctly for a single package build with
> cmake?
> 
> Any examples in the tree?

ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
LIBCEC_DEPENDENCIES += rpi-userland
LIBCEC_CONF_OPTS += \
        -DCMAKE_C_FLAGS="$(TARGET_CFLAGS) -lvcos -lvchiq_arm" \
        -DCMAKE_CXX_FLAGS="$(TARGET_CXXFLAGS) \
                -I$(STAGING_DIR)/usr/include/interface/vmcs_host/linux \
                -I$(STAGING_DIR)/usr/include/interface/vcos/pthreads"
endif

or

ifeq ($(BR2_ARM_CPU_ARMV7A)$(BR2_ARM_CPU_HAS_NEON),yy)
GNURADIO_CONF_OPTS += -DCMAKE_C_FLAGS="$(TARGET_CFLAGS) -march=armv7-a"
endif

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] kmsxx: not available on m68k

[Peter Korsgaard]

>>>>> "Waldemar" == Waldemar Brodkorb <wbx@openadk.org> writes:

Hi,

 >> Will you send patches to do this?

 > I can try. But now I am back to my original problem, how do I
 > overwrite CFLAGS/CXXFLAGS correctly for a single package build with
 > cmake?

 > Any examples in the tree?

I'm far from a cmake expert, but I would expect something like:

KMSXX_CONF_OPTS += -DCMAKE_C_FLAGS="$(TARGET_CFLAGS) -fno-dwarf2-cfi-asm"

Would work. rpi-userland does something similar.

-- 
Bye, Peter Korsgaard