| Message ID | 20170213093502.26507-1-peter@korsgaard.com |
|---|---|
| State | Rejected |
| Headers | show |
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" == 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.
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
>>>>> "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?
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
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
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
>>>>> "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.
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
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(+)