All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: libnl vs. libnl2 madness
Date: Thu, 3 Feb 2011 11:12:42 +0100	[thread overview]
Message-ID: <20110203101242.GF3265@jama> (raw)
In-Reply-To: <201102031054.08764.ml@vdm-design.de>

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

On Thu, Feb 03, 2011 at 10:54:08AM +0100, Thomas Zimmermann wrote:
> On Thursday 03 February 2011 10:32:53 Stefan Schmidt wrote:
> > Hello.
> >
> > The last hours I was trying to compile wpa_supplicant with nl80211 support.
> > That needs netlink support through libnl or libnl2.
> >
> > Enabling the option to use libnl2, not that easy to find, still breaks with
> > missing header files. Checking the libnl2 source shows that they are
> > provided. After some head on the table banging I found:
> >
> > commit 880e00d3b7ccf66d9421a06bc28e553e07842b59
> > Author: Michael 'Mickey' Lauer <mickey@vanille-media.de>
> > Date:   Tue Nov 24 16:33:06 2009 +0000
> >
> >     libnl2: change includedir to not step over libnl1; also convert to new
> > staging
> 
> At that time there was just one recipe depending on libnl2 and that was FSO2.
> I think one month ago JaMa has build the first SHR image without libnl(1), 

yes after couple of changes
http://git.openembedded.org/cgit.cgi/openembedded/log/?h=org.openembedded.dev&qt=grep&q=libnl

> until then it was impossible because of some important parts. I'm not sure but 
> i think the main blocker was bluez4 (Can't check now).

Yes older bluez4 with nl plugin (which was removed later).

and:
http://gitorious.org/~jama/angstrom/jama-shr-experimental/commit/70b13d30b335b8fd67116d3bc0834382a77bc319
81      ANGSTROM_BLACKLIST_pn-bmon = "bmon depends on libnl we want libnl2"
82	ANGSTROM_BLACKLIST_pn-crda = "crda depends on libnl we want libnl2"
83	ANGSTROM_BLACKLIST_pn-hostap-daemon = "hostap-daemon depends on libnl we want libnl2"
84	ANGSTROM_BLACKLIST_pn-ibrdtn = "ibrdtn depends on libnl we want libnl2"
85	ANGSTROM_BLACKLIST_pn-iw = "iw depends on libnl we want libnl2"
86	ANGSTROM_BLACKLIST_pn-lowpan-tools = "lowpan-tools depends on libnl we want libnl2"
87	ANGSTROM_BLACKLIST_pn-networkmanager = "networkmanager depends on libnl we want libnl2"
88	ANGSTROM_BLACKLIST_pn-networkmanager-openvpn = "networkmanager-openvpn depends on libnl we want libnl2"
89	ANGSTROM_BLACKLIST_pn-pstree = "pstree depends on libnl we want libnl2"
90	ANGSTROM_BLACKLIST_pn-rfkill = "rfkill depends on libnl we want libnl2"

I didn't check if those can be built with libnl2 or if they work properly with libnl2.

But be aware that we had enough issues in runtime (build passes ok) caused by libnl1 built in same sysroot 
as libnl2 (that's why I had to blacklist libnl2 in SHR).

From GNUtoo's report about issues with libnl1 in runtime..(when both libnl are built in same sysroot and libnl1 was rebuilt later)
<snip>
root@htcdream ~ # phoneuid
BUG: route/class_api.c:42
phoneuid: route/class_api.c:42: rtnl_class_register: Assertion `0' failed.
Aborted
</snip>

And also be aware that after blacklisting it, doing just bitbake -c clean libnl libnl2 wasn't 
enough to rebuild all apps properly against libnl2, I had to manually remove all traces of 
libnl1 like shlibs etc (not sure why).

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

  reply	other threads:[~2011-02-03 10:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03  9:32 libnl vs. libnl2 madness Stefan Schmidt
2011-02-03  9:54 ` Thomas Zimmermann
2011-02-03 10:12   ` Martin Jansa [this message]
2011-02-03 12:42     ` Stefan Schmidt
2011-02-03 14:08       ` Stefan Schmidt
2011-02-09 10:00         ` Stefan Schmidt
2011-02-09 10:20           ` Koen Kooi
2011-02-09 10:46             ` Stefan Schmidt
2011-02-11 10:15     ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110203101242.GF3265@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.