ntrack 013 doesn't build with libnl 3.0

Bug #743879 reported by Arkadiusz Miśkiewicz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ntrack
Fix Released
Wishlist
Alexander Sack

Bug Description

There is libnl 3.0 with a promise of stable API/ABI, so it's worth to support it. Fortunately libnl 2.0 and libnl 3.0 API look the same in the part used by ntrack, so simple patch attached.

Related branches

Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote :
Revision history for this message
Alexander Sack (asac) wrote :

thanks. I agree that we should add libnl-3 support for next release.

Note: I am planning to relicense ntrack to either LGPL2.1 (or later) or even a BSD/MIT style non-copyleft license. Current license is LGPL 3.0 (or later).

So before taking your patch, I wonder if you are OK with me relicensing your code to any of those licenses above (if it comes to it).

Changed in ntrack:
importance: Undecided → Wishlist
milestone: none → 014
status: New → Triaged
Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote :

I'm OK with all mentioned licenses.

Alexander Sack (asac)
Changed in ntrack:
status: Triaged → In Progress
assignee: nobody → Alexander Sack (asac)
Revision history for this message
Alexander Sack (asac) wrote :

all your emails are hidden for logged in users in your launchpad profile:

https://launchpad.net/~arekm

you can change that setting so i can take your Name <email> as author for committing.

Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote :
Download full text (4.3 KiB)

Email property changed.

Don't know if the problem is in my patch or in ntrack 0.13... or somewhere else but kded4 dies now for me. Previously (0.11 and libnl 1) it worked fine.

So not sure if my patch is guilty or is something else going on.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fc8760 (LWP 5631)]
0x00007fffe217d1af in ntrack_arch_get_rfds (self=0x0) at ntrack.c:117
117 if (module.ftbl->get_rfds)
(gdb) bt
#0 0x00007fffe217d1af in ntrack_arch_get_rfds (self=0x0) at ntrack.c:117
#1 0x00007fffe2385dbc in QNtrack::QNtrack (this=0x830770) at QNtrack.cpp:48
#2 0x00007fffe2385ea8 in QNtrack::instance () at QNtrack.cpp:39
#3 0x00007fffe258f5ef in ?? () from /usr/lib64/kde4/kded_networkstatus.so
#4 0x00007fffe258de38 in ?? () from /usr/lib64/kde4/kded_networkstatus.so
#5 0x00007fffe258eb5c in QObject* KPluginFactory::createInstance<NetworkStatusModule, QObject>(QWidget*, QObject*, QList<QVariant> const&) ()
   from /usr/lib64/kde4/kded_networkstatus.so
#6 0x00007ffff5efc4db in KPluginFactory::create (this=0x83b760, iface=0x7ffff5f4f240 "KDEDModule", parentWidget=0x0, parent=0x640da0, args=...,
    keyword=<value optimized out>) at /usr/src/debug/kdelibs-4.6.1/kdecore/util/kpluginfactory.cpp:203
#7 0x00007ffff7bd3d5a in create<KDEDModule> (this=0x640da0, s=<value optimized out>, onDemand=<value optimized out>)
    at /usr/src/debug/kdelibs-4.6.1/kdecore/util/kpluginfactory.h:503
#8 Kded::loadModule (this=0x640da0, s=<value optimized out>, onDemand=<value optimized out>) at /usr/src/debug/kdelibs-4.6.1/kded/kded.cpp:410
#9 0x00007ffff7bd46e6 in Kded::loadModule (this=0x640da0, obj=<value optimized out>, onDemand=true) at /usr/src/debug/kdelibs-4.6.1/kded/kded.cpp:362
#10 0x00007ffff7bd4984 in Kded::messageFilter (message=<value optimized out>) at /usr/src/debug/kdelibs-4.6.1/kded/kded.cpp:205
#11 0x00007ffff5a6e168 in ?? () from /usr/lib64/libQtDBus.so.4
#12 0x00007ffff5a7281a in ?? () from /usr/lib64/libQtDBus.so.4
#13 0x00007fffea509bbc in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#14 0x00007ffff5a64225 in ?? () from /usr/lib64/libQtDBus.so.4
#15 0x00007ffff5aa9a44 in ?? () from /usr/lib64/libQtDBus.so.4
#16 0x00007ffff572af6e in QObject::event(QEvent*) () from /usr/lib64/libQtCore.so.4
#17 0x00007ffff636c9a4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#18 0x00007ffff637154a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#19 0x00007ffff709e886 in KApplication::notify (this=0x7fffffffe1a0, receiver=0x6250d0, event=0x625f20)
    at /usr/src/debug/kdelibs-4.6.1/kdeui/kernel/kapplication.cpp:311
#20 0x00007ffff5716c5c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#21 0x00007ffff571a45f in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQtCore.so.4
#22 0x00007ffff5742363 in ?? () from /usr/lib64/libQtCore.so.4
#23 0x00007ffff2c8cc23 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#24 0x00007ffff2c8d400 in ?? () from /usr/lib64/libglib-2.0.so.0
#25 0x00007ffff2c8...

Read more...

Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote :

Ok, found out a reason.

nl3 module needs to be linked with libnl-route for route_obj_ops symbol, too. Unfortunately libnl 3.0 doesn't have pkgconfig file for this lib, so something like that:

 AC_SUBST(LIBNL3_CFLAGS)
+if [ -n "$LIBNL3_LIBS" ]; then
+ LIBNL3_LIBS="$LIBNL3_LIBS -lnl-route"
+fi
 AC_SUBST(LIBNL3_LIBS)

is needed.

That solves my crash. This also means that ntrack lib is not graceful when it cannot load it's modules which likely should be reported as another bug.

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 743879] Re: ntrack 0.13 doesn't build with libnl 3.0

On Mon, Mar 28, 2011 at 08:56:13PM -0000, Arkadiusz Miśkiewicz wrote:
> Ok, found out a reason.
>
> nl3 module needs to be linked with libnl-route for route_obj_ops symbol,
> too. Unfortunately libnl 3.0 doesn't have pkgconfig file for this lib,
> so something like that:
>
> AC_SUBST(LIBNL3_CFLAGS)
> +if [ -n "$LIBNL3_LIBS" ]; then
> + LIBNL3_LIBS="$LIBNL3_LIBS -lnl-route"
> +fi
> AC_SUBST(LIBNL3_LIBS)
>

isnt this a bug in .pc file?

 - Alexander

Revision history for this message
Alexander Sack (asac) wrote :

On Mon, Mar 28, 2011 at 08:56:13PM -0000, Arkadiusz Miśkiewicz wrote:
> That solves my crash. This also means that ntrack lib is not graceful
> when it cannot load it's modules which likely should be reported as
> another bug.

yes, thats a separate bug. please file.

 - Alexander

Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote : Re: ntrack 0.13 doesn't build with libnl 3.0

> isnt this a bug in .pc file?

I would rather say that separate pc files are missing for nl-xxx libraries.

Revision history for this message
Alexander Sack (asac) wrote :

i filed bug 748988 for the 'ntrack should handle "no backend" status gracefully' issue you mentioned.

Revision history for this message
Alexander Sack (asac) wrote :

> I would rather say that separate pc files are missing for nl-xxx libraries.

can you check with libnl upstream maintainers what they think about this issue? for the time being i will explicitly add -lnl-route.

Alexander Sack (asac)
summary: - ntrack 0.13 doesn't build with libnl 3.0
+ ntrack 013 doesn't build with libnl 3.0
Revision history for this message
Arkadiusz Miśkiewicz (arekm) wrote :
Revision history for this message
Alexander Sack (asac) wrote :

------------------------------------------------------------
revno: 289 [merge]
fixes bug(s): https://launchpad.net/bugs/743879
committer: Alexander Sack <email address hidden>
branch nick: ntrack
timestamp: Sun 2011-04-03 14:23:10 +0200
message:
  add support for libnl-3.0 - lp:743879
   + merged branch lp:~asac/ntrack/lp743879
   + Thanks to Arkadiusz Miśkiewicz for the prototype patch
------------------------------------------------------------

Changed in ntrack:
status: In Progress → Fix Committed
Revision history for this message
Alexander Sack (asac) wrote :

great... now i am not sure what to do.

Maybe wait till next release and then say that we require that version and move to use the .pc files. I don't like the idea of having to maintain build tweaks for each minor version ;).

Anyway, guess once libnl 3.0.1 is released we can revisit. let me know if the libnl3 fix committed works good for you.

Revision history for this message
Alexander Sack (asac) wrote :
Changed in ntrack:
milestone: 014 → none
status: Fix Committed → Fix Released
milestone: none → 014
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.