From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 34EF3E00B88; Thu, 5 Jun 2014 09:04:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MIME_HTML_ONLY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (rjohnweber[at]gmail.com) * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.160.172 listed in list.dnswl.org] Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id CEB30E00A44 for ; Thu, 5 Jun 2014 09:04:42 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 79so987288ykr.31 for ; Thu, 05 Jun 2014 09:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9xGubZFcEYsbZ1nkku+JNa5mXBNbaxozCEe0KfW7cuQ=; b=C4b/IdHcVXE0edeMPFTK4V5qV6B+ADW2w3xkJ+r62qrn15hFSW735umdQJx/B19Ik9 /x4PiSo/scqd9L6/pTbwqHoDdwL4IwJ7Ko8LUscz6+url4V8iYJfCF3X9UWMcXWR12NZ 1fuFoF1QV9ooKdbUZWneAPXgmFRRtzWySzrm04SWFlfikFQ2i4S79TANr1lvFK2LOS0q 9vTmFYTZiB+ifiYv02IKKVZ6vVvKSRhWHY8aHRgWdRW2A/iD3tvPKbpX5Al6FCVZmYqc TAE2kdK2CikG+epZxNQyKeIinCRnsyWI02iQ2x/4gWhJNDzwbcjvM+GNH98IUBptMnJb O1Fw== X-Received: by 10.236.208.33 with SMTP id p21mr85845872yho.17.1401984281412; Thu, 05 Jun 2014 09:04:41 -0700 (PDT) Received: from goober-2.local ([75.76.197.2]) by mx.google.com with ESMTPSA id h34sm9301527yhm.52.2014.06.05.09.04.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 09:04:40 -0700 (PDT) Message-ID: <53909518.3040000@gmail.com> Date: Thu, 05 Jun 2014 11:04:40 -0500 From: John Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: meta-freescale@yoctoproject.org References: <082cdb4c7ee4438b83d7ac64cf6fb90c@BLUPR08MB471.namprd08.prod.outlook.com> <56804cc41a4d408ea26fc782d3843f9d@BLUPR08MB471.namprd08.prod.outlook.com> In-Reply-To: <56804cc41a4d408ea26fc782d3843f9d@BLUPR08MB471.namprd08.prod.outlook.com> Subject: Re: How do I add the QSQLITE driver to the yocto build for wandboard X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:04:45 -0000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stephen,

On 6/5/14, 10:19 AM, Stephen Munnings wrote:
-----Original Message-----
From: Erik Botö [mailto:erik.boto@pelagicore.com] 
Sent: Wednesday, June 04, 2014 10:53 AM
To: Stephen Munnings
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] How do I add the QSQLITE driver to the yocto build for wandboard

Hi Stephen,

On Fri, May 30, 2014 at 11:45 PM, Stephen Munnings <Stephen.Munnings@nuvation.com> wrote:
-----Original Message-----
From: Stephen Munnings
Sent: Friday, April 11, 2014 12:14 PM
To: 'Erik Botö'
Cc: 'meta-freescale@yoctoproject.org'
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: meta-freescale@yoctoproject.org
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:erik.boto@pelagicore.com]
Sent: Friday, April 11, 2014 3:00 AM
To: Stephen Munnings
Cc: meta-freescale@yoctoproject.org
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 <Stephen.Munnings@nuvation.com> 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
meta-freescale@yoctoproject.org
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: erik.boto@pelagicore.com
=============================================

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,
Erik

We 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

Hi Eric,

I removed anything in local.conf, and used a bbappends file instead.
The "bitbake-layers show-appends | grep qtbase" command shows:
---
qtbase_5.1.1.bb:
  /home/user/ELKAY/yocto/fsl-community-bsp/sources/meta-fsl-arm/qt5-layer/recipes-qt/qt5/qtbase_5.1.1.bbappend
  /home/user/ELKAY/yocto/fsl-community-bsp/sources/meta-gdbman/recipes-gdbman/gdbman/qtbase_5.1.1.bbappend
---
The last line is the .bbappend file for my application


The .bbappend file is simple, and looks like this:
--
(comments removed)
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PACKAGECONFIG_append = " sql-sqlite"
--

I still don't get the QSQLITE plugin appearing to be created in the build.


(This section should perhaps be a separate thread all on its own)
I am wondering if it is related to some other strange issues I have been having:

1.  I have not been able to compile our Qt5 app without first installing an (external) tool-chain, made with "bitbake meta-toolchain" and adding its path to the PATH environment variable.
  (I would get the message [make: arm-poky-linux-gnueabi-gcc: Command not found] when the first module was attempted to be compiled)
  I found this a little strange, since one would think that the host toolchain would automatically be available to build a cross-compiled application under yocto.
Assuming that you're using an x86 host, then the step you took makes sense.  You can also do this:
$ 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.

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.
Probably will be solved by the environment settings above, but that is just a guess.

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,