Unwanted dependency on X from ppp

Unwanted dependency on X from ppp

[Mats Kärrman]

Hi Everyone!

I'm building a small "headless" embedded system with OE and the Angstrom distro. A normal rootfs build consists of about 1500 tasks. Everything fine so far.

Now I wanted to include the ppp daemon in my build and thus just added "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a lot of X/display related stuff is downloaded and built. I fail to see the connection.

I'm afraid I'm not using the latest trunk or release of OE but any suggestions or directions on how to find/eliminate the cause of the problem would be greatly appreciated!

Best Regards,
Mats

Re: Unwanted dependency on X from ppp

[Bob Foerster]

Hi Mats,

On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote:

> Hi Everyone!
>
> I'm building a small "headless" embedded system with OE and the Angstrom
> distro. A normal rootfs build consists of about 1500 tasks. Everything fine
> so far.
>
> Now I wanted to include the ppp daemon in my build and thus just added
> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a
> lot of X/display related stuff is downloaded and built. I fail to see the
> connection.
>

Are the X/display items you're concerned about actually making it into the
final image, or just being built?  If they are ending up in the image, then
it will take some investigation as to why that's happening. If they're just
being built there is probably not much you can do, but the following may
help shed some light as to why they are built.

To understand why adding ppp pulls in various X/display packages, keep in
mind that what is downloaded and built does not directly correlate to what
ends up in the image.  Often, recipes may provide several packages which
have a broad set of build time dependencies, but these don't all necessarily
end up in the image.

For tracking down dependencies, you can fire up the dependency explorer gui
for bitbake:
bitbake -g -u depexp ppp

Doing this and following the trail, one sees:
ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for
bluez-libs) -> gst-plugins-base -> gtk+ -> libx*

Given this dependency chain, we start to see why building ppp causes various
gtk+ and X packages to be built. The bluez4 recipe provides a package
gst-plugin-bluez, causing a build time dependency on gst-plugins-base.
 gst-plugins-base depends on many things, including gtk+.  As a result of
these dependencies, many packages end up being built.  The shlibs code in OE
automatically detects the run time libs required for a given package and
appropriately associates run time dependencies on them.  As such, unless one
adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+,
libx*, etc packages to make it into the final image.  If they are, then
there is another dependency that is pulling them into the image and needs
explored.  For a little bit more background on build vs run time
dependencies, see [1].

Hope that helps clarify a bit.
Bob

[1]
http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem



> I'm afraid I'm not using the latest trunk or release of OE but any
> suggestions or directions on how to find/eliminate the cause of the problem
> would be greatly appreciated!
>
> Best Regards,
> Mats
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Unwanted dependency on X from ppp

[Mats Kärrman]

Thank you Bob!

You're my hero, honestly!

The "clean build" time concerns me though. I will need bluez components,
but not gstreamer so I guess I'll set out to find a neat way to override
the default bluez recipe and get rid of that dependency.

// Mats

________________________________________     
From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob Foerster [robert@erafx.com]
Sent: Wednesday, July 13, 2011 4:18 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Unwanted dependency on X from ppp

Hi Mats,

On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote:

> Hi Everyone!
>
> I'm building a small "headless" embedded system with OE and the Angstrom
> distro. A normal rootfs build consists of about 1500 tasks. Everything fine
> so far.
>
> Now I wanted to include the ppp daemon in my build and thus just added
> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a
> lot of X/display related stuff is downloaded and built. I fail to see the
> connection.
>

Are the X/display items you're concerned about actually making it into the
final image, or just being built?  If they are ending up in the image, then
it will take some investigation as to why that's happening. If they're just
being built there is probably not much you can do, but the following may
help shed some light as to why they are built.

To understand why adding ppp pulls in various X/display packages, keep in
mind that what is downloaded and built does not directly correlate to what
ends up in the image.  Often, recipes may provide several packages which
have a broad set of build time dependencies, but these don't all necessarily
end up in the image.

For tracking down dependencies, you can fire up the dependency explorer gui
for bitbake:
bitbake -g -u depexp ppp

Doing this and following the trail, one sees:
ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for
bluez-libs) -> gst-plugins-base -> gtk+ -> libx*

Given this dependency chain, we start to see why building ppp causes various
gtk+ and X packages to be built. The bluez4 recipe provides a package
gst-plugin-bluez, causing a build time dependency on gst-plugins-base.
 gst-plugins-base depends on many things, including gtk+.  As a result of
these dependencies, many packages end up being built.  The shlibs code in OE
automatically detects the run time libs required for a given package and
appropriately associates run time dependencies on them.  As such, unless one
adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+,
libx*, etc packages to make it into the final image.  If they are, then
there is another dependency that is pulling them into the image and needs
explored.  For a little bit more background on build vs run time
dependencies, see [1].

Hope that helps clarify a bit.
Bob

[1]
http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem



> I'm afraid I'm not using the latest trunk or release of OE but any
> suggestions or directions on how to find/eliminate the cause of the problem
> would be greatly appreciated!
>
> Best Regards,
> Mats
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Unwanted dependency on X from ppp

[Bob Foerster]

On Wed, Jul 13, 2011 at 11:37 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote:

> Thank you Bob!
>
> You're my hero, honestly!
>

No problem, happy to help!


> The "clean build" time concerns me though. I will need bluez components,
> but not gstreamer so I guess I'll set out to find a neat way to override
> the default bluez recipe and get rid of that dependency.
>
>
I would normally override this in my layer using amend.inc. You can probably
do it with bbappend too, but I'm not too familiar with that.

The basic idea to remove that dependency would be to override/modify
bluez4.inc (or any other offending files):
 - remove gst-plugins-base from DEPENDS so gstreamer and all dependencies
don't get built
 - fix configuring/compiling of the package after removing the dependency
(like modify EXTRA_OECONF to get rid of the enable gstreamer switch)

That may not be all that needs done, but that should at least get you on the
right track.

Enjoy!
Bob

// Mats
>
> ________________________________________
> From: openembedded-devel-bounces@lists.openembedded.org [
> openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob
> Foerster [robert@erafx.com]
> Sent: Wednesday, July 13, 2011 4:18 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Unwanted dependency on X from ppp
>
> Hi Mats,
>
> On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se
> >wrote:
>
> > Hi Everyone!
> >
> > I'm building a small "headless" embedded system with OE and the Angstrom
> > distro. A normal rootfs build consists of about 1500 tasks. Everything
> fine
> > so far.
> >
> > Now I wanted to include the ppp daemon in my build and thus just added
> > "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and
> a
> > lot of X/display related stuff is downloaded and built. I fail to see the
> > connection.
> >
>
> Are the X/display items you're concerned about actually making it into the
> final image, or just being built?  If they are ending up in the image, then
> it will take some investigation as to why that's happening. If they're just
> being built there is probably not much you can do, but the following may
> help shed some light as to why they are built.
>
> To understand why adding ppp pulls in various X/display packages, keep in
> mind that what is downloaded and built does not directly correlate to what
> ends up in the image.  Often, recipes may provide several packages which
> have a broad set of build time dependencies, but these don't all
> necessarily
> end up in the image.
>
> For tracking down dependencies, you can fire up the dependency explorer gui
> for bitbake:
> bitbake -g -u depexp ppp
>
> Doing this and following the trail, one sees:
> ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for
> bluez-libs) -> gst-plugins-base -> gtk+ -> libx*
>
> Given this dependency chain, we start to see why building ppp causes
> various
> gtk+ and X packages to be built. The bluez4 recipe provides a package
> gst-plugin-bluez, causing a build time dependency on gst-plugins-base.
>  gst-plugins-base depends on many things, including gtk+.  As a result of
> these dependencies, many packages end up being built.  The shlibs code in
> OE
> automatically detects the run time libs required for a given package and
> appropriately associates run time dependencies on them.  As such, unless
> one
> adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+,
> libx*, etc packages to make it into the final image.  If they are, then
> there is another dependency that is pulling them into the image and needs
> explored.  For a little bit more background on build vs run time
> dependencies, see [1].
>
> Hope that helps clarify a bit.
> Bob
>
> [1]
>
> http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem
>
>
>
> > I'm afraid I'm not using the latest trunk or release of OE but any
> > suggestions or directions on how to find/eliminate the cause of the
> problem
> > would be greatly appreciated!
> >
> > Best Regards,
> > Mats
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Unwanted dependency on X from ppp

[Mike Westerhof]

On 7/13/2011 10:37 AM, Mats Kärrman wrote:
> Thank you Bob!
> 
> You're my hero, honestly!
> 
> The "clean build" time concerns me though. I will need bluez components,
> but not gstreamer so I guess I'll set out to find a neat way to override
> the default bluez recipe and get rid of that dependency.

This topic comes up for discussion now and again, and nothing really
ever gets resolved.  There are two camps, it seems -- I fall into the
group that cares about build time as much as I care about what ends up
in the image.

In any case, perhaps the following incantations might be helpful; they
are somewhat dated (double-check these against the current recipes!),
but I used these in my local.conf to get rid of useless X11 builds on my
build machines:

DEPENDS_pn-bluez-libs = "dbus"
EXTRA_OECONF_pn-bluez-libs = "--disable-tools --disable-network
--disable-serial --disable-service --disable-usb --enable-alsa"

DEPENDS_pn-bluez4 = "alsa-lib virtual/libusb0 dbus-glib libsndfile1"
EXTRA_OECONF_pn-bluez4 = "--disable-gstreamer --enable-alsa --enable-usb
--enable-netlink --enable-tools --enable-bccmd --enable-hid2hci
--enable-dfutool --enable-hidd --enable-pand --enable-dund
--disable-cups --enable-test --enable-manpages --enable-configfiles
--enable-initscripts --disable-pcmciarules"

DEPENDS_pn-dbus = "expat glib-2.0 virtual/libintl libsm libice"
EXTRA_OECONF_X_pn-dbus = "--without-x"

-Mike (mwester)

> 
> // Mats
> 
> ________________________________________     
> From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob Foerster [robert@erafx.com]
> Sent: Wednesday, July 13, 2011 4:18 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Unwanted dependency on X from ppp
> 
> Hi Mats,
> 
> On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote:
> 
>> Hi Everyone!
>>
>> I'm building a small "headless" embedded system with OE and the Angstrom
>> distro. A normal rootfs build consists of about 1500 tasks. Everything fine
>> so far.
>>
>> Now I wanted to include the ppp daemon in my build and thus just added
>> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a
>> lot of X/display related stuff is downloaded and built. I fail to see the
>> connection.
>>
> 
> Are the X/display items you're concerned about actually making it into the
> final image, or just being built?  If they are ending up in the image, then
> it will take some investigation as to why that's happening. If they're just
> being built there is probably not much you can do, but the following may
> help shed some light as to why they are built.
> 
> To understand why adding ppp pulls in various X/display packages, keep in
> mind that what is downloaded and built does not directly correlate to what
> ends up in the image.  Often, recipes may provide several packages which
> have a broad set of build time dependencies, but these don't all necessarily
> end up in the image.
> 
> For tracking down dependencies, you can fire up the dependency explorer gui
> for bitbake:
> bitbake -g -u depexp ppp
> 
> Doing this and following the trail, one sees:
> ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for
> bluez-libs) -> gst-plugins-base -> gtk+ -> libx*
> 
> Given this dependency chain, we start to see why building ppp causes various
> gtk+ and X packages to be built. The bluez4 recipe provides a package
> gst-plugin-bluez, causing a build time dependency on gst-plugins-base.
>  gst-plugins-base depends on many things, including gtk+.  As a result of
> these dependencies, many packages end up being built.  The shlibs code in OE
> automatically detects the run time libs required for a given package and
> appropriately associates run time dependencies on them.  As such, unless one
> adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+,
> libx*, etc packages to make it into the final image.  If they are, then
> there is another dependency that is pulling them into the image and needs
> explored.  For a little bit more background on build vs run time
> dependencies, see [1].
> 
> Hope that helps clarify a bit.
> Bob
> 
> [1]
> http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem
> 
> 
> 
>> I'm afraid I'm not using the latest trunk or release of OE but any
>> suggestions or directions on how to find/eliminate the cause of the problem
>> would be greatly appreciated!
>>
>> Best Regards,
>> Mats
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> 

Re: Unwanted dependency on X from ppp

[Mats Kärrman]

Thanks again, Mike & Bob,

I added something in the line of Mike's suggestion to my machine conf and
got the number of tasks down to just over 2200 and the build runs reasonably
fast. There are still a bunch of X native related dependencies generated from
dbus but I found no easy way to get rid of them.

Still - a huge improvement!

// Mats
________________________________________
From: Mike Westerhof [mike@mwester.net]
Sent: Wednesday, July 13, 2011 6:11 PM
To: openembedded-devel@lists.openembedded.org
Cc: Mats Kärrman
Subject: Re: [oe] Unwanted dependency on X from ppp

On 7/13/2011 10:37 AM, Mats Kärrman wrote:
> Thank you Bob!
>
> You're my hero, honestly!
>
> The "clean build" time concerns me though. I will need bluez components,
> but not gstreamer so I guess I'll set out to find a neat way to override
> the default bluez recipe and get rid of that dependency.

This topic comes up for discussion now and again, and nothing really
ever gets resolved.  There are two camps, it seems -- I fall into the
group that cares about build time as much as I care about what ends up
in the image.

In any case, perhaps the following incantations might be helpful; they
are somewhat dated (double-check these against the current recipes!),
but I used these in my local.conf to get rid of useless X11 builds on my
build machines:

DEPENDS_pn-bluez-libs = "dbus"
EXTRA_OECONF_pn-bluez-libs = "--disable-tools --disable-network
--disable-serial --disable-service --disable-usb --enable-alsa"

DEPENDS_pn-bluez4 = "alsa-lib virtual/libusb0 dbus-glib libsndfile1"
EXTRA_OECONF_pn-bluez4 = "--disable-gstreamer --enable-alsa --enable-usb
--enable-netlink --enable-tools --enable-bccmd --enable-hid2hci
--enable-dfutool --enable-hidd --enable-pand --enable-dund
--disable-cups --enable-test --enable-manpages --enable-configfiles
--enable-initscripts --disable-pcmciarules"

DEPENDS_pn-dbus = "expat glib-2.0 virtual/libintl libsm libice"
EXTRA_OECONF_X_pn-dbus = "--without-x"

-Mike (mwester)

>
> // Mats
>
> ________________________________________
> From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob Foerster [robert@erafx.com]
> Sent: Wednesday, July 13, 2011 4:18 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Unwanted dependency on X from ppp
>
> Hi Mats,
>
> On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote:
>
>> Hi Everyone!
>>
>> I'm building a small "headless" embedded system with OE and the Angstrom
>> distro. A normal rootfs build consists of about 1500 tasks. Everything fine
>> so far.
>>
>> Now I wanted to include the ppp daemon in my build and thus just added
>> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a
>> lot of X/display related stuff is downloaded and built. I fail to see the
>> connection.
>>
>
> Are the X/display items you're concerned about actually making it into the
> final image, or just being built?  If they are ending up in the image, then
> it will take some investigation as to why that's happening. If they're just
> being built there is probably not much you can do, but the following may
> help shed some light as to why they are built.
>
> To understand why adding ppp pulls in various X/display packages, keep in
> mind that what is downloaded and built does not directly correlate to what
> ends up in the image.  Often, recipes may provide several packages which
> have a broad set of build time dependencies, but these don't all necessarily
> end up in the image.
>
> For tracking down dependencies, you can fire up the dependency explorer gui
> for bitbake:
> bitbake -g -u depexp ppp
>
> Doing this and following the trail, one sees:
> ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for
> bluez-libs) -> gst-plugins-base -> gtk+ -> libx*
>
> Given this dependency chain, we start to see why building ppp causes various
> gtk+ and X packages to be built. The bluez4 recipe provides a package
> gst-plugin-bluez, causing a build time dependency on gst-plugins-base.
>  gst-plugins-base depends on many things, including gtk+.  As a result of
> these dependencies, many packages end up being built.  The shlibs code in OE
> automatically detects the run time libs required for a given package and
> appropriately associates run time dependencies on them.  As such, unless one
> adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+,
> libx*, etc packages to make it into the final image.  If they are, then
> there is another dependency that is pulling them into the image and needs
> explored.  For a little bit more background on build vs run time
> dependencies, see [1].
>
> Hope that helps clarify a bit.
> Bob
>
> [1]
> http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem
>
>
>
>> I'm afraid I'm not using the latest trunk or release of OE but any
>> suggestions or directions on how to find/eliminate the cause of the problem
>> would be greatly appreciated!
>>
>> Best Regards,
>> Mats
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>

Re: Unwanted dependency on X from ppp

[Dr. Michael Lauer]

Mike,

I think this is quite useful and should be codified as as a .inc.

Cheers,

:M:

Re: Unwanted dependency on X from ppp

[Petr Štetiar]

Mats Kärrman <Mats.Karrman@tritech.se> [2011-07-14 11:51:18]:

> Thanks again, Mike & Bob,
> 
> I added something in the line of Mike's suggestion to my machine conf and
> got the number of tasks down to just over 2200 and the build runs reasonably
> fast. There are still a bunch of X native related dependencies generated from
> dbus but I found no easy way to get rid of them.

Another example, here's excerpt from my ts72xx/recipes/libpcap/libpcap_1.1.1.bbappend:

DEPENDS_ts72xx := "${@oe_filter_out('bluez-libs', bb.data.getVar('DEPENDS', d, 1), d)}"

It filters out bluez-libs dependency for ts72xx (headless) machine. I think,
that it's courtesy of kergoth (or Tartarus?) from #oe.

-- ynezz