Re: [yocto] [PATCH] qt4-native: depend on icu-native to fix build on systems with icu >=59
> I should give you a heads up: we (the yocto project) are going to remove qt4 > builds from the autobuilder altogether, sometime during this cycle. The repo > will stay, and patches will be accepted though. Thanks for the heads up. > So it's up to you to solve these issues, but I wouldn't want to take > patches that fix up older releases, while the master branch remains broken. > We have a 'master first' policy :) master first makes sense if master is going to be supported going forward, but given the extremely stale state of qt4, I don't expect we'll be able to keep it working (at least as a complete unit) for very much longer. And we probably shouldn't :) . At some point there is going to be a last release that works with qt4, forever. Would it be reasonable to disable icu usage in meta-qt4 master while switching pyro & morty to using the icu-native package? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] qt4-native: depend on icu-native to fix build on systems with icu >=59
Yep, for `master` that is certainly true. For `morty` & `pyro` though, meta-qt4 could keep working by using icu-native. The source of this issue being qt4's general incompatibility with C++ 11 (we build with c++98 because of build errors with the newer std) makes me wonder if it will even be possible to continue supporting qt4 going forward. This may turn out like the openssl conflicts in that we'll need to disable qt4's use of icu entirely. On Wed, Jun 7, 2017 at 8:24 AM, Alexander Kanavin <alexander.kana...@linux.intel.com> wrote: > On 06/07/2017 07:19 AM, Cody P Schafer wrote: >> >> Previously, qt4-native would use the system icu to build. >> >> Trying to build against a system ICU 59, however, fails with this root >> error: >> >> | In file included from /usr/include/unicode/uversion.h:30:0, >> | from tools/qlocale_icu.cpp:46: >> | /usr/include/unicode/umachine.h:347:13: error: ‘char16_t’ does not name >> a type; did you mean ‘wchar_t’? >> | typedef char16_t UChar; >> | ^~~~ >> | wchar_t >> > > We will introduce icu 59 to oe-core at some point (in fact, I have a patch > queued), and then this fix will no longer work. > > You need to fix Qt4 itself. > > Alex > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] qt4-native: depend on icu-native to fix build on systems with icu >=59
Previously, qt4-native would use the system icu to build. Trying to build against a system ICU 59, however, fails with this root error: | In file included from /usr/include/unicode/uversion.h:30:0, | from tools/qlocale_icu.cpp:46: | /usr/include/unicode/umachine.h:347:13: error: ‘char16_t’ does not name a type; did you mean ‘wchar_t’? | typedef char16_t UChar; | ^~~~ | wchar_t May have to do with our use of `-std=gnu98++`. Signed-off-by: Cody P Schafer <d...@codyps.com> --- recipes-qt4/qt4/qt4-native.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-qt4/qt4/qt4-native.inc b/recipes-qt4/qt4/qt4-native.inc index 5a873de..a14a647 100644 --- a/recipes-qt4/qt4/qt4-native.inc +++ b/recipes-qt4/qt4/qt4-native.inc @@ -1,5 +1,5 @@ SUMMARY = "Qt version 4 tools and support files for the build host" -DEPENDS = "zlib-native dbus-native" +DEPENDS = "zlib-native dbus-native icu-native" SECTION = "libs" HOMEPAGE = "http://qt-project.org/; PROVIDES = "qt4-tools-native" -- 2.13.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4][PATCH] nativesdk-qt4-tools: ensure --disable-static is not passed
This recipe presumes it can build the qt4-tools as static, and does not
install any of it's built libraries. If we don't remove
`--disable-static`, it attempts to use non-existent shared libraries
(many of them aren't even built), resulting in either link failures at
build time or (occasionally) at populate_sdk time due to the lack of a
provider for the shared libraries.
Signed-off-by: Cody P Schafer <d...@codyps.com>
---
recipes-qt4/qt4/nativesdk-qt4-tools.inc | 4
1 file changed, 4 insertions(+)
diff --git a/recipes-qt4/qt4/nativesdk-qt4-tools.inc
b/recipes-qt4/qt4/nativesdk-qt4-tools.inc
index 54bf2a1..44faf83 100644
--- a/recipes-qt4/qt4/nativesdk-qt4-tools.inc
+++ b/recipes-qt4/qt4/nativesdk-qt4-tools.inc
@@ -8,6 +8,10 @@ FILESEXTRAPATHS =. "${FILE_DIRNAME}/qt4-${PV}:"
inherit nativesdk qmake2
+# This recipe builds the tools as static executables (using static libraries),
+# so we need to avoid disabling them.
+DISABLE_STATIC = ""
+
SRC_URI =
"http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-everywhere-opensource-src-${PV}.tar.gz
\
file://0001-qlibraryinfo-allow-to-set-qt.conf-from-the-outside-u.patch \
file://0004-configure-qmake-is-already-built-in-qt4-tools-native.patch \
--
2.10.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] bump linux-yocto-dev to 3.18?
It looks like http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/ is still sitting at 3.17.6, are their plans to merge the 3.18 changes? Or does linux-yocto-dev wait on stable kernel releases? Or is this blocked on something else I'm unaware of? -- Cody -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Questions regarding adding a new llvm based cross-compiler
On Fri, Oct 17, 2014 at 1:48 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Oct 17, 2014 at 09:07:19AM +0100, Paul Barker wrote: On 16 October 2014 18:46, Cody P Schafer d...@codyps.com wrote: Hi all, I'm working on creating a layer for the rust compiler (which uses llvm) and was wondering if there were any best practices and/or examples people could point me at. Are you using llvm recipes from meta-oe (or at least starting from them)? I wasn't. Rust packages a particular llvm version already (and ties it into it's build scripts). I'm planning on just using that one. I haven't tried it yet, but I've asked Servo developer, how they do cross-builds and he said that it's really simple with Rust and Cargo, which support cross-compilation by design. Well: From what I've found, crossbuilds work fine if you're using one of a small set of blessed triples (ie: not arm-poky-linux-gnueabi, but arm-unknown-linux-gnueabihf), and you don't set any special CFLAGS/LDFLAGS variables (which oe does). And the infrastructure is not in place to allow packagers to easily add/use different triples and linkers (rustc calls gcc/cc to link it's programs, and as a result needs to know where it is). -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Questions regarding adding a new llvm based cross-compiler
On Sun, Oct 19, 2014 at 4:10 AM, Khem Raj raj.k...@gmail.com wrote: [...] I have started to integrate clang into oe Which probably is quitquite similar to this effortwise. Its very prelimpreliminary. Check my github repo. I should add it to layer index (repo link for the interested: https://github.com/kraj/meta-clang) Khem: the complication for me is rustc doesn't magically build for all targets it supports (at the moment) when using gcc as the compiler/linker (rustc calls an external binary, typically gcc or cc to link it's code). As a result, I can't just build for -native. I'm currently fighting with cross.bbclass to convince it to do what I want. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Questions regarding adding a new llvm based cross-compiler
Hi all, I'm working on creating a layer for the rust compiler (which uses llvm) and was wondering if there were any best practices and/or examples people could point me at. The compiler is designed to be built for multiple targets at once (unlike the gcc model of having a single compiler build for each target). Q: Does this mean that I don't need to create a '-cross' package? (And just use '-native'?) Q: What about a -runtime package? Will one be needed? (The compiler can build runtime libs for multiple targets, so a '-native' could include the target runtime libs). Thanks -- Cody -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] cmake + qt4e in bitbake fails to detect/supply all requested qt include paths
This works with qt4 (non-embedded) when built natively, is there some
bitbake incantation I'm missing to have qt4e+cmake work? Or does qt4e
just not play nice with cmake?
Error message:
| [100%] Building CXX object CMakeFiles/kiosk-web.dir/kiosk.cc.o
|
/home/cody/obj/yocto/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
-DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -march=armv7-a
-mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8
--sysroot=/home/cody/obj/yocto/tmp/sysroots/beaglebone -O2 -pipe -g
-feliminate-unused-debug-types -fvisibility-inlines-hidden
-fpermissive -isystem
/home/cody/obj/yocto/tmp/sysroots/x86_64-linux/usr/include/qt4
-isystem /home/cody/obj/yocto/tmp/sysroots/x86_64-linux/usr/include/qt4/QtGui
-isystem /home/cody/obj/yocto/tmp/sysroots/x86_64-linux/usr/include/qt4/QtCore
-o CMakeFiles/kiosk-web.dir/kiosk.cc.o -c
/home/cody/obj/yocto/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/kiosk-web/0.0+gitrAUTOINC+dfe3db9730-r0/git/kiosk-web/kiosk.cc
|
/home/cody/obj/yocto/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/kiosk-web/0.0+gitrAUTOINC+dfe3db9730-r0/git/kiosk-web/kiosk.cc:6:28:
fatal error: QGraphicsWebView: No such file or directory
| #include QGraphicsWebView
| ^
Relevent portion of my kiosk-web_0.1.bb file (remainder is srcs, revs,
desc, and license junk)
S = ${WORKDIR}/git/${PN}
inherit cmake qt4e
do_configure () {
cmake_do_configure
}
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project(kiosk-web)
find_package(Qt4 REQUIRED)
set(kiosk-web_SOURCES kiosk.cc)
set(QT_USE_QTWEBKIT 1)
include(${QT_USE_FILE})
add_definitions(${QT_DEFINITIONS})
add_executable(kiosk-web ${kiosk-web_SOURCES})
target_link_libraries(kiosk-web ${QT_LIBRARIES})
kiosk.cc :
#include QApplication
#include QGraphicsScene
#include QGraphicsView
#include QGraphicsWebView
#include QWebSettings
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QGraphicsScene scene;
QGraphicsView view(scene);
view.setFrameShape(QFrame::NoFrame);
view.setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
view.setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
QGraphicsWebView webview;
webview.load(QUrl(http://google.com/;));
webview.setResizesToContents(true);
scene.addItem(webview);
view.showFullScreen();
return app.exec();
}
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] libgdiplus: uses giflib
Depend on giflib-native, without this we end up pulling in the system's
one (which may be the wrong version)
Signed-off-by: Cody P Schafer d...@codyps.com
---
recipes-mono/libgdiplus/libgdiplus-native_2.10.8.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-mono/libgdiplus/libgdiplus-native_2.10.8.bb
b/recipes-mono/libgdiplus/libgdiplus-native_2.10.8.bb
index 25dfbbd..cec1fbe 100644
--- a/recipes-mono/libgdiplus/libgdiplus-native_2.10.8.bb
+++ b/recipes-mono/libgdiplus/libgdiplus-native_2.10.8.bb
@@ -14,7 +14,7 @@ SRC_URI =
https://github.com/mono/libgdiplus/archive/${PV}.tar.gz \
inherit autotools pkgconfig native
-DEPENDS =+ cairo-native freetype-native fontconfig-native libxft-native
libpng-native pango-native
+DEPENDS =+ cairo-native freetype-native fontconfig-native libxft-native
libpng-native pango-native giflib-native
SRC_URI[md5sum] = 6fd45bbb9843f5a8851b5f44e2a5dd04
SRC_URI[sha256sum] =
45c533dc72af0a24d1d3a8097873f5fe1670107fe7e6d08fb71ae586c87a0f1d
--
2.0.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
