Using files generated by other recipes in Yocto

B

3

5

Note: The general question is in bold at the end of this post.

I'm trying to build PostGIS 2.2.7 with Yocto (Rocko) for my Linux i.MX6 based embedded system. First of all, I have installed PostgreSQL 9.4.15 from OpenEmbedded Layers (https://layers.openembedded.org/layerindex/recipe/5558/) and all the (mandatory) dependencies I could find in the installation manual (https://download.osgeo.org/postgis/docs/postgis-2.2.7.pdf): GNU C, Proj4, GEOS, LibXML2 and JSON-C. Adding the following packages to my image (local.conf):

IMAGE_INSTALL_append += " postgresql postgresql-dev postgresql-server-dev proj proj-dev json-c json-c-dev geos geos-dev libxml2 libxml2-dev"

Then I tried to compile PostGIS inside my target system, and making some changes to a couple of files I succeeded.

Finally, as long as I want to integrate PostGIS into my image with Yocto, I wrote the postgis recipe (I have a "files" folder with the postgis-2.2.7.tar.gz tar):

DESCRIPTION = "PostGIS is a spatial database extender for PostgreSQL object-relational database. It adds support for geographic objects allowing location queries to be run in SQL."

SECTION = "devel"

LICENSE = "GPL-3.0"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/GPL-3.0;md5=c79ff39f19dfec6d293b95dea7b07891"

DEPENDS += "gcc postgresql libxml2 geos proj json-c"

RDEPENDS_${PN} = "postgresql-server-dev postgresql-dev"

SRC_URI = "file://postgis-2.2.7.tar.gz"

EXTRA_OECONF +=  "\
    --without-raster \
    --with-pgconfig=${STAGING_BINDIR_CROSS}"

inherit autotools pkgconfig

do_configure () {
    oe_runconf
}

do_compile () {
    oe_runmake
}

But when I run bitbake in order to build my image, I get the following ERROR coming from PostGIS' do_configure function

| configure: error: the user-specified pg_config file /home/danlor/yocto-hmcu/build-hmcu/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/postgis/2.2.7-r0/recipe-sysroot/usr/bin/crossscripts does not exist 
| NOTE: The following config.log files may provide further information. 
| NOTE: /home/danlor/yocto-hmcu/build-hmcu/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/postgis/2.2.7-r0/build/config.log 
| ERROR: configure failed | WARNING: exit code 1 from a shell command. 
| ERROR: Function failed: do_configure (log file is located at /home/danlor/yocto-hmcu/build-hmcu/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/postgis/2.2.7-r0/temp/log.do_configure.45983)

Of course, this error is triggered because the executable pg_config is not located in ${STAGING_BINDIR_CROSS}, either nowhere else but in the work folder of PostgreSQL (in ../image/usr/bin and ../package/usr/bin subfolders). My /tmp/sysroots folder is empty also.

So, the real question is: How can I access to the files generated by other recipes from my own recipe? I need to specify that path (along with others, from the rest of dependencies) in order to configure, compile and install PostGIS into my image.

EDIT 26/07/2018:

pg_config can be found in the following directories inside the postgresql ${WORKDIR}

./package/usr/bin/pg_config
./package/usr/bin/.debug/pg_config
./package/usr/src/debug/postgresql/9.4.15-r0/postgresql-9.4.15/src/bin/pg_config
./postgresql-9.4.15/src/bin/pg_config
./build/src/bin/pg_config
./build/src/bin/pg_config/pg_config
./packages-split/postgresql-dbg/usr/bin/.debug/pg_config
./packages-split/postgresql-dbg/usr/src/debug/postgresql/9.4.15-r0/postgresql-9.4.15/src/bin/pg_config
./packages-split/postgresql/usr/bin/pg_config
./image/usr/bin/pg_config

Band answered 24/7, 2018 at 10:14 Comment(0)

B

4

sysroots are the method for sharing files across recipes.

If pg_config is in in ${D}${bindir} (i.e. you see it in the work folder's image/usr/bin), you can add to a postgres_x.x.x.bbappend file:

SYSROOT_DIRS += "${bindir}"

Which will copy all the files from postgresql's bindir into postgis's recipe-sysroots folder. This isn't a great idea, as pg_config is a binary and cross compiled so it won't run on your system. This is why /usr/bin/ from your image directory isn't copied to sysroots by default.

Instead of directories, you can also modify the staging:

sysroot_stage_all_append() {
  install -d ${SYSROOT_DESTDIR}${bindir}/crossscripts
  install -m 0755 ${D}${bindir}/pg-config ${SYSROOT_DESTDIR}${bindir}/crossscripts/pg-config
}

Bandanna answered 26/7, 2018 at 20:44 Comment(6)

This would only work if you're not cross-compiling... and since you're using bitbake/yocto, you're probably cross-compiling. Honestly, though, the current postgis configure script is not cross-compiler friendly; you'll probably want to re-write configure.ac to not use pg_config and instead provide paths and version information another way. – Bandanna 26/7, 2018 at 22:12

Thank you! That's a huge work though, isn't it? Is there a better way to include PostGIS into my image? May be I can take a pre-built package from the Raspberry Pi repos or something...If there's not, I'll deal with it that way! – Band 27/7, 2018 at 8:7

You could just run pg_config on your embedded system so it shows you all the variables it contains, and copy them into a pg-config.sh script (such that they'll pick up the correct sysroot paths). Then use that as an alternative to the binary pg_config. – Bandanna 28/7, 2018 at 16:37

I'm following your advice but I'm not able to make the script available to my PostGIS recipe...I'm installing it in ${D}${bindir} but it seems like it is not being included in the recipe-sysroot of postgis – Band 30/7, 2018 at 14:55

these recipes may help: github.com/cnelson711/osm-bb – Bandanna 31/7, 2018 at 16:54

Wow! Thank you very much! Surely they do help! However, I'm not able to fully compile PostGIS yet, because do_compile function fails (some Makefile is trying to compile against /liblwgeom/.libs/liblwgeom.a, but liblwgeom.a doesn't exist, only .so and .la libs are generated), but I'm currently working on it. I really appreciate your help! – Band 2/8, 2018 at 8:35

P

5

First of all there are a couple of things you need to check on your recipe:

You dont have to DEPEND on gcc since it will automatically be added thought BASEDEPENDS , and it will actually add the correct CROSS compiler, in this case you are depending on the native compiler instead (It will probably help you out to check the output of bitbake -e).
Also it is likely that you don't have to override do_configure() / do compile()

Now, to answer your question:

What you actually want to is to have access to files INSTALLED by other recipes, in this specific case you say the file pg_config is generated by the postgresql recipe, then usually what you need to do is add postgresql to DEPENDS , this way, before compiling the postgis recipe, bibtake will perform a task called prepare_recipe_sysroot which takes all files installed from packages listed on DEPENDS and adds them to recipe-sysroot/... or recipe-sysroot-native/... , this way when cross compiling your package it will have access to all that it requires (or at least all that you listed it requires).

Since you already listed postgresql on DEPENDS, I can only assume that the postgresql recipe is not installing the pg_config file, to do this you need to make sure that it is being installed on do_install() from the postgresql recipe and that it is packaged via the FILES_${PN} variable (again on the postgresql recipe).

To check that the file is being provided by the postgresql recipe, you can look for the file inside the sysroot-providers directory (which is inside your TMPDIR), under the popstgresql directory.

Hope that helps

Postremogeniture answered 26/7, 2018 at 6:28 Comment(2)

First of all, thank you for your answer! Yes, the pg_config executable is generated (compiled from .c and .h) by the postgresql recipe, however, there is no reference to "pg_config" in the posgresql recipe (nor postgresql.inc). Also, no /sysroot-* contains the file. Even if I add it to FILES_${PN} (in a .bbappend FILES_${PN} += "${bindir}/pg_config ")... – Band 26/7, 2018 at 12:18

You can't use a non-native binary compiled by a different recipe as part of the build of another recipe. pg_config will have been cross-compiled to the target architecture and it is not appropriate to use on the host machine. – Nuremberg 3/4 at 22:19

B

4