|
Hi Stephen, On 6/5/14, 10:19 AM, Stephen Munnings
wrote:
Assuming that you're using an x86 host, then the step you took makes sense. You can also do this:-----Original Message----- From: Erik Botö [mailto:[email protected]] Sent: Wednesday, June 04, 2014 10:53 AM To: Stephen Munnings Cc: [email protected] Subject: Re: [meta-freescale] How do I add the QSQLITE driver to the yocto build for wandboardHi Stephen, On Fri, May 30, 2014 at 11:45 PM, Stephen Munnings <[email protected]> wrote:-----Original Message----- From: Stephen Munnings Sent: Friday, April 11, 2014 12:14 PM To: 'Erik Botö' Cc: '[email protected]' Subject: RE: [meta-freescale] How do I add the QSQLITE driver to the yocto build for wandboard Hi Erik, Thanks. That worked. My concerns about the driver not being built were unfounded. For reference, the missing "link" - which would likely have been obvious if I were more expert in using yocto - was the use of "PACKAGECONFIG_append = " sql-sqlite"" in order to enable the feature. This was never specifically noted (or I missed it) in the reading that I did about PACKAGECONFIG. Other items I had read also seemed to indicate that this package was already enabled - but not conclusively so. Gratefully, Stephen Munnings -----Original Message----- From: Stephen Munnings Sent: Friday, April 11, 2014 10:00 AM To: 'Erik Botö' Cc: [email protected] Subject: RE: [meta-freescale] How do I add the QSQLITE driver to the yocto build for wandboard Hi Erik, Thanks for the help. I will be trying this out to see what happens. I had found the PACKAGECONFIG lines in recipes-qt/qt5/qtbase.inc (and something in qtbase-native.inc as well) but it was unclear how to "invoke" those packages (or if they were already being "invoked"). Your post has shed some light on that. It is also unclear whether "invoking" this package is sufficient to get the plugin driver built. There were some hints that it only allowed for some library to be built that was a pre-req for the driver (still unclear on that) I will try this all out, and get back with my results - good, bad, or incomplete. Thanks again, Stephen -----Original Message----- From: Erik Botö [mailto:[email protected]] Sent: Friday, April 11, 2014 3:00 AM To: Stephen Munnings Cc: [email protected] Subject: Re: [meta-freescale] How do I add the QSQLITE driver to the yocto build for wandboard Hi Stephen, Qt5 can be configured with a number of features disabled or enabled, the standard way of doing this in Yocto is using the PACKAGECONFIG feature [1]. In meta-qt5 there's a qtbase.inc which set up a pretty small set of enabled features as default, so what I would suggest is that you create a qtbase_%.bbappend where you extend those features. If you look at https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase .inc you see that there are a number of different PACKAGECONFIG options relating to SQL: PACKAGECONFIG[sql-ibase] = "-sql-ibase,-no-sql-ibase" PACKAGECONFIG[sql-mysql] = "-sql-mysql,-no-sql-mysql,mysql" PACKAGECONFIG[sql-psql] = "-sql-psql,-no-sql-psql,postgresql" PACKAGECONFIG[sql-odbc] = "-sql-odbc,-no-sql-odbc" PACKAGECONFIG[sql-oci] = "-sql-oci,-no-sql-oci" PACKAGECONFIG[sql-tds] = "-sql-tds,-no-sql-tds" PACKAGECONFIG[sql-db2] = "-sql-db2,-no-sql-db2" PACKAGECONFIG[sql-sqlite2] = "-sql-sqlite2,-no-sql-sqlite2,sqlite" PACKAGECONFIG[sql-sqlite] = "-sql-sqlite,-no-sql-sqlite,sqlite3" In order to enable one of those you need to make sure that the PACKAGECONFIG variable contains e.g. "sql-sqlite". This can be done by adding PACKAGECONFIG_append = " sql-sqlite" to qtbase_%.bbappend. [1] - http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html , search for PACKAGECONFIG Cheers, Erik On Thu, Apr 10, 2014 at 4:40 PM, Stephen Munnings <[email protected]> wrote:Hi All, I am new to this list, so please be gentle in correcting flaws in my post (all sorts). I am trying to get a Qt5 application to run on a Wandboard (remotely debugged from a development host). I can get the Qt5 application running on the host machine (Ubuntu 13.10 VM). This application uses sqlite to access a database. When I attempt to remotely debug it on the target (wandboard), I get the messages: QSqlDatabase: QSQLITE driver not loaded QSqlDatabase: available drivers: (nothing appears in the list). As I understand it, this means that I do not have the QSQLITE driver (plugin) built and installed on my target system. (A search shows it to be non-existent on the target system - as opposed to simply not found) One of my co-workers has been successful in generating this driver (and much other important stuff) by doing a "separate install" of Qt5.1.1 onto the target machine. Separate meaning that it was built external to the yocto build infrastructure (but using the cross-toolchain generated by yocto). We have added Qt5 to the yocto build, using the meta-qt5 layer and following the wiki article: http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandb o ard My understanding (which may or may not be correct) is that I should be able to get the appropriate libraries (and in this case plugins) cross-compiled and built for the target by using appropriate directives in the yocto build. (Either as a new layer, or as modifications to the local.conf and/or the bblayers.conf) However, as I dig down through layers (pun intended) and layers of code, control files, documentation, etc., I am becoming horribly confused about how best to go about this. Could some kind person give me some quick guidance on how to get the yocto build to create the QSQLITE driver plugin for the target file system (wandboard)? Thanks in advance. -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale-- ============================================= Erik Botö Senior Software Engineer Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)76 881 72 03 E-Mail: [email protected] ============================================= Hi Erik, anybody else able to comment, I have moved from the wandboard, to our own custom board (based on the wandboard). As such, I have added some layers. One for our "Distro" One for our BSP (not much different there from wandboard - just some small changes) One for the application (Qt-based) that will be running on this board. Strangely, the QSSQLITE drivers are not being built, and I cannot figure it out. I have created a qtbase_5.1.1.bbappend file with the PACKAGECONFIG_append = " sql-sqlite" line in it. (This is part of the layer for the Qt-based application) I also have a line like that in the local.conf, which is how I got it to work the first time. However, with or without that line in local.conf, it no longer seems to work for the new board. I have learned a lot about yocto in the last few weeks, but this is still confusing and stumping me.Where have you placed the bbappend file? It must be in a place where bitbake will look, which is specified by your layers layer.conf file. You can check it bitbake has picked it up with: bitbake-layers show-appends | grep qtbase Also, if you try to add it via local.conf you should probably use something like below in order to just add it for qtbase: PACKAGECONFIG_pn-qtbase += "sql-sqlite" Cheers, ErikWe are running the dora branch. Any tips on what to check out, and/or what to look for? I am able to see other plugins being created in our final image, like "platforms". In directory tmp/work/<arch>/qtbase/5.1.1-r0/sysroot-destdir/usr/lib/qt5/plugins -- Stephen Munnings Sr. Design Engineer | 519.594.0976 www.nuvation.com $ bitbake meta-ide-support $ source build/tmp/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi This takes advantage of setting up the environment for the toolchain and the libraries/headers in your sysroots without having to build an explicit SDK installer (like in meta-toolchain). It also configures the CFLAGS and such as well, so your applications will be built with the same floating point ABI. This is typically what I do prior to launching Eclipse or QTCreator. That way those applications start with the Yocto environment variables already loaded. Probably will be solved by the environment settings above, but that is just a guess.2. Once I added the PATH of the cross-toolchain, the compile step was apparently mixing hard and soft floating point setups. I solved(?) this by adding the following lines to the Qt *.pro file: QMAKE_CFLAGS_DEBUG+= -mfloat-abi=hard QMAKE_CFLAGS+= -mfloat-abi=hard QMAKE_CXXFLAGS += -mfloat-abi=hard 3. The subsequent executable (in the build distribution file system) would not run. I finally tracked this down (using readelf) to the executable wanting the "interpreter" of /lib/ld-linux-so.3 while the only file available was /lib/ld-linux-armhf-so.3. When I (for experiment purposes) made a link of the first, pointing to the second, the program ran. 4. The Qt application is being built in a directory [---/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi] - The only components in this directory are the recipes that I have created. A few components are being built in [---/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi] - these components are: firmware-imx, gpu-viv-bin-mx6q, gst-plugins-base, libdrm, mesa, and qtbase Some components are being built in [---/tmp/work/graphic_board-poky-linux-gnueabi] - there are 23 items in there. The graphic_board (as opposed to the graphic-board) seems to be only coming from something that is kernel configuration based, as the only place graphic_board is used (instead of graphic-board) is in the kernel configuration. The vast majority of components are being built in [---/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi] - 149 items [---/tmp/work/all-poky-linux] has 2 components: packagegroup-core-ssh-openssh, and update-rc.d Finally, [--/tmp/work/x86_64-linux] has 95 items, all of which I expect to be cross-tools of some kind (all the component names end in -native) All of this "smells" of some kind of oversight that should have been installed into a layer or recipe from the very beginning. (In my application recipes, more likely than not) My (edited to remove sensitive information, but hopefully not functionally different in any way) application recipe is attached if one wants to look at it to see what might be missing... Sorry to inundate you with all these details, but I have been struggling with a fairly well documented (at the highest levels) system (yocto) where more detailed items are very poorly documented, and are quite hard to extract from the underlying code (because of the complexity of the system). For example, how the PACKAGE_ARCH variable is used, and how it affects things. Regards, |
-- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
