Monday 21 February 2011

daily hack: library dependency trees

Many a time, ok, well, quite frequently at least I've needed to see what is bringing a dependency into an application or a library I'm working on. At the moment, I'm working on removing some useless dependencies for performance and misc reasons, so I'm finding information like that very helpful.

So, scripting to the rescue.

Use is simple:

burchr@virgin:~/code/scripts(master+)% genlibtree.rb /usr/lib/libQtCore.so
Dependency tree for /usr/lib/libQtCore.so
 /usr/lib/libQtCore.so
* /usr/lib/libpthread.so.0
* /usr/lib/libz.so.1
* /usr/lib/libdl.so.2
* /usr/lib/libgthread-2.0.so.0
** /usr/lib/libglib-2.0.so.0
** /usr/lib/librt.so.1
** /usr/lib/libc.so.6
* /usr/lib/libstdc++.so.6
** /usr/lib/libm.so.6
** /usr/lib/ld-linux.so.2
** /usr/lib/libgcc_s.so.1

There's a few gotchas in that it won't list repeated dependencies, only searches /usr/lib, etc - but it more or less works. Patches welcome. I hope you find it useful in your quest to remove unneeded dependencies - it is worthwhile running it over your work, at least, to see what bloat you're pulling in.

(Much thanks to many folks, but especially Thiago Macieria of Qt and other fame, for giving me a bit of a crash course in some of how shared libraries work under the hood.)

edit: I should probably note that this may not necessarily provide a full picture. Shared objects may still be loaded at runtime, and in the case of QtGui, are in the form of things like image plugins and other things. It's still useful, though.

edit 2: since I've had a few people point out that it is horrific ruby, I'd just like to note that yes, I am not in fact a perfectionist when it comes to throwaway tools I write in five minutes. Patches welcome. ;)

Labels: , , , , , ,

Friday 11 February 2011

the bomb has hit...

...now we need to let the dust settle.

So, unless you've been living in a cave, you've probably heard about the Nokia news by now. I of course have thoughts and opinions about this, not all of them clear. So I'll just stick with what I think about the future for Qt and MeeGo for now.

A lot of people around the Qt development community (some users, some contributors, and some Nokians) have been worrying. There have also been a few people asking about forking, and to them, I would say: not yet. Let the dust settle. Right now, Qt themselves don't know exactly what the future holds, but I would expect this to be clarified in the near future. Thiago has also clarified that open governance of Qt is still an ongoing project.

I don't personally see too much changing here, because despite news of Symbian's perhaps timely death, MeeGo still needs Qt, and I don't think MeeGo is in any imminent danger. Here's why.

  • MeeGo is not just Nokia

    Intel is also involved in MeeGo, and in addition to that, there are other partners and OEMs.

    This will not change.
  • MeeGo is open

    This means that anyone who wants to continue the work and contribute, can. There's no barriers, no licensing fees, and no patent worries. This is attractive to hardware manufacturers. Thanks to (trying) to reuse upstream components, it's also a less expensive alternative than Android.

    This will not change.
  • Nokia did, right at the outset of the announcement say, they are continuing work on it

    Yes, it is true that they also announced that they are reducing their R&D spending on it, but perhaps this isn't such a bad thing. Perhaps lower spending will enable them to spend on what really matters, and focus on getting something out the door.
That's not that I think today's news is great, or even good - but I'd like to encourage calmness. Let's all have some time to digest the information and think about what exactly it means.

I might write more about this once I've had a chance to collect my own opinions a little more. I'm certainly concerned, and interested, but there is no need to panic.

Labels: , , , , , , ,