autotools & pkg_config: ./autogen.sh fails to find a previously built package

[Frederik Carlier]

Hi Sergio,

Running 'snapcraft stage' results in the same error. The order in which the projects are built seems fine - libplist is built before libusbmuxd, so that should be OK. The file stage/lib/pkgconfig/libplist.pc is generated and has the correct content.

I've created a Gist with the build output, in case it helps:
https://gist.github.com/qmfrederik/b46f723476bf1d190e04

Let me know if there's anything I can do to troubleshoot this issue.

Thanks!

Frederik. 

From: Sergio Schvezov [mailto:sergio.schvezov at canonical.com] 
Sent: woensdag 9 december 2015 14:09
To: Frederik Carlier <frederik.carlier at quamotion.mobi>
Cc: snappy-app-devel at lists.ubuntu.com
Subject: Re: autotools & pkg_config: ./autogen.sh fails to find a previously built package

On Tue, Dec 8, 2015 at 9:49 PM, Frederik Carlier <mailto:frederik.carlier at quamotion.mobi> wrote:
Hi,

I'm creating a Snappy package for the libimobiledevice toolset. It consists of a couple of projects which depend on each other, and use pkg-config to detect the presence of the dependencies.
You can find my .yaml file at https://github.com/quamotion/snappy-arm/blob/master/libimobiledevice/snapcraft.yaml

I'm having an issue building libusbmuxd. libusbmuxd depends on libplist. The ./autogen.sh script will try to detect libplist using pkg-config.
I've updated my .yaml file to make ure libusbmuxd is built after libplist.

At this time, when I build my package using snapcraft build, I get the following error:

> configure: error: Package requirements (libplist >= 1.11) were not met:
>
> No package 'libplist' found
>
> Consider adjusting the PKG_CONFIG_PATH environment variable if you
> installed software in a non-standard prefix.

I was wondering whether snapcraft is supposed to automatically update the PKG_CONFIG_PATH variable as required, or whether I need to make any changes to my .yaml file to get this to work?

Can you try running 'snapcraft stage'?
There is an intrinsic bug in here which won't change for 1.x when using `after`, this is fixed in 2.x which will only target 16.04