Archive for the ‘Windows’ Category

Libraries and link interfaces

Friday, October 30th, 2009

Today I received an e-mail from Vincent about some strange warnings dpkg-shlibdeps was showing when building from source the Wt packages on Debian:

dpkg-shlibdeps: warning: symbol pthread_join used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_delete used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_setspecific used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_detach used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_getspecific used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_create used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.

He asked if I knew what was that (a dpkg-shlibdeps bug?) and what did it mean, it case it was correct.

That error means pthread_join, pthread_mutexattr_destroy, etc are used by libwt.so and libwthttp.so but those libraries are not linked to libpthread.so by Wt’s buildsystem. I. e. the linker command line when putting libwt.so and libwthttp.so together does not have a “-lpthread“.

Is dpkg-shlibdeps right about that? Yes, it is:

  • libwt.so uses libpthread.so in the XML library (Wt bundles the sources ot MiniXML and compiles them as part of libwt.so)
  • libwthttp.so uses libpthread.so in WServer.C

So, if the buildsystem is not linking libwt.so and libwthttp.so to libpthread.so, why doesn’t linking fail with “unresolved reference” errors? It’s because of the link interface in Boost is wrong.

Link interface? What’s that?

If you are reading me via Planet KDE, you probably know what I’m talking about because Alex has written about this. If you don’t know what I’m talking about, keep reading.

Say you have libA.so, libB.so and libC.so.

  • libA.so does not link to any external library, save for glibc
  • libB.so links only to libA.so and glibc
  • libC.so links only libB.so and glibc

When you run ldd libC.so, what will you get? This?

$ ldd libC.so

linux-gate.so.1 => (0xb7f66000)
libB.so => /usr/lib/libB.so
libc.so.6 => /lib/tls/i686/cmov/libc.so.6
/lib/ld-linux.so.2 (0xb7f67000)

or this?

$ ldd libC.so

linux-gate.so.1 => (0xb7f66000)
libB.so => /usr/lib/libB.so
libA.so => /usr/lib/libA.so < =======
libc.so.6 => /lib/tls/i686/cmov/libc.so.6
/lib/ld-linux.so.2 (0xb7f67000)

The answer is you’ll see the second output: libC.so is linking to libA.so, although when you linked it you only did gcc -o libC.so libC.c -lB (no -lA, so no explicit linking to libA.so):

libC -> libB -> libA

Why is that? Why is libA.so being dragged to libC.so? It’s because of what we call “link interface”

As libC.so links to libB.so, by default, libC.so’s ELF header will have every library libB.so links to as NEEDED: libB.so’s dependencies have been transitively passed into libC.so! Usually that’s not what you want, therefore it is possible to specify a “reduced link interface”: given that libA.so is only used internally in libB.so (users of libB.so do not need to use any type or function defined in libA), there is no need to link libC.so to libA.so.

Therefore:

  • As libwt.so and libwthttp.so link to libboost_thread-mt.so from Boost
  • In Debian, Boost is compiled with threads (i. e. it links to libpthread.so)
  • Boost does not publish a reduced link interface but the full link interface (i. e. every dependency of Boost is transitively passed into applications/libraries using Boost)

… even though libwt.so and libwthttp.so were not linking to libpthread.so explicitly, they were picking libpthread.so from libboost_thread-mt.so and no linkage error happened. If libboost_thread-mt.so would not export libpthread.so (it should not!), linkage of libwt.so and libwthttp.so would have failed and the authors of Wt would have noticed the bug in their build system.

While this is not a critical issue, it makes your application/library load slower, because it needs to resolve and load the NEEDED libraries.

Please note this discussion is valid for any operating system, including Windows and Mac OS X.

If you use CMake as your build system and you want to adopt a reduced link interface, take a look at the CMake docs for TARGET_LINK_LIBRARIES, particularly the LINK_INTERFACE_LIBRARIES section:

Library dependencies are transitive by default. When this target is linked into another target then the libraries linked to this target will appear on the link line for the other target too. See the LINK_INTERFACE_LIBRARIES target property to override the set of transitive link dependencies for a target.

target_link_libraries( LINK_INTERFACE_LIBRARIES
[[debug|optimized|general] ] …)

The LINK_INTERFACE_LIBRARIES mode appends the libraries to the LINK_INTERFACE_LIBRARIES and its per-configuration equivalent target properties instead of using them for linking. Libraries specified as “debug” are appended to the the LINK_INTERFACE_LIBRARIES_DEBUG property (or to the properties corresponding to configurations listed in the DEBUG_CONFIGURATIONS global property if it is set). Libraries specified as “optimized” are appended to the the LINK_INTERFACE_LIBRARIES property. Libraries specified as “general” (or without any keyword) are treated as if specified for both “debug” and “optimized”.

NB: The comments in this blog do not work due to a hosting issue

CMake-ifying git

Wednesday, October 8th, 2008

I’m going to use git for a project of mine and instead of parsing git’s output (which is the adviced way to use it from your application), I thought I’d rather use libgit and link to it. The first step was getting rid of autohell and moving to CMake.

This patch against git’s current master branch includes the CMakeLists.txt file and a few modifications to the source (mostly due to the different way variable replacement works in autotools vs CMake).

So far, only libgit, libxdiff and git are built. Will I go go for the other binaries (gitweb, gitk, etc)? I’m not sure, as I’m not interested but it shouldn’t be difficult to CMake-ize those.

I think the move from autotools to CMake could be very useful for the msysgit* developers, as they no longer would depend on MSys*

* I have not tried to build git on Windows with my CMakeLists.txt yet, I’ll do it tomorrow

** It’s not actually true yet: I run two bourne shell-scripts but I could easily rewrite those in CMake, too.

Update I’ve produced a new patch, as the old one did not perform a few needed renames

Raising awareness of KDE on Windows

Sunday, October 5th, 2008

Most of my coworkers use Qt4 but only on Windows. Some of them did not even know KDE existed, much less that since KDE 4.1 there are official packages and an official installer for Windows.

Last week, I wandered around the office, occasionally assaulting people to show them KDE on Windows, the API docs, this-and-that widget, answering their questions (mostly technical), etc (if you know how tackatpromotioned Marble at past aKademy-s, you know what I did :-) )

So, what was the reaction of people to KDE? Surprisingly, extremely good! I was expecting more resistance to the fact that to use K* classes, KParts, etc you have to convert your QApplication to a KApplication but they went like “the advantages of using KDE classes and KDE’s ActiveX [that's how some of them call KParts] are so obvious I will do that as soon as I installing a development version of KDE on Windows is easy”. People specially liked the Kate, oKular and KPlato KParts (although I showed KPlato 1.6 and only on Linux). The pie-like ToolBox menu in Amarok also received some praising.

My conclusion: I really think we should raise more awareness of KDE among Windows developers and the “wander-around-and-assault-for-no-reason” approach works very well. Try it with your Win32 coworkers and friends and blog about KDE on Windows. Let’s get some momentum for KDE4 on Windows!

ZeroC ICE and CMake

Friday, August 15th, 2008

I was asked today for the CMake modules for finding ZeroC ICE I had talked about in January. Here they are:

Record a screencast with ffmpeg

Wednesday, July 23rd, 2008

ffmpeg has been able to record a screencast on X11 for a long time now, using the x11grab input format and the :0.0 device (for the first instance of X). You’d run
ffmpeg -f x11grab -y -r 12 -s 800x600 -i :0.0+480,200 -vcodec ffv1 -sameq ./out.avi
and get a lossless video of the upper right 800×600 area of a 1280×800 desktop. Easy. You could even transcode to a lossy format (such as H.264, Xvid or Theora) if you had a powerful machine.

On Windows it was not that easy. First of all, Windows is not X11, so x11grab does not work on Windows. You need to use GDI or DirectX but ffmpeg did not have support for GDI or DirectX capture. If you wanted screen-grabbing features in you application, either you developed your own solution (ugly, specially because of the video encoding part) or you used Camtasia Studio (Wink does not include a DLL or ActiveX component you can use in your app).

Ramiro Polla and Christophe Gisquet had a heated discussion about one and a half years ago and some very interesting code was shown. Unfortunately, neither Ramiro’s nor Christophe’s code would work with current ffmpeg.

Today I’ve finally brought Ramiro’s code up to date and it works with ffmpeg trunk. It is not perfect, though: it does not capture the mouse pointer, contextual menus shown as a result of a right-click and video scaling and color is not perfect (ffplay shows the video a little blue-ish). Patch. I’ll try and bring Christophe’s code up to date tomorrow, or fix Ramiro’s code.

PS: A request for ffmpeg developers: please, replace your custom configure script with some cross-platform build system. I like CMake but Scons, Waf and others would also do.

Amarok 2 on Windows (will full codec support)

Friday, July 18th, 2008

Yesterday I stayed up until 4:30 AM while trying to fix Amarok to works on Windows and when I got it to build it was so late I was too tired to test it. So I fired it this morning and this is the result (click for larger images):

I have tested and it plays MP3, WMA, APE and whatever Magnatune streams on. Built with Visual C++ 2008.

Update Two more screenshots added and in case you were wondering, yes, Plasma works!

Amarok 2 on Windows

Sunday, June 29th, 2008

Yesterday I fixed the Phonon DirectShow 9 backend for Windows. Now audio and video are available to KDE applications on Windows, which means Amarok 2-trunk works! Currently, it can only play .WMA files (I think I have to install the .ax files for the MP3, MIDI, WAV, etc codecs in the KDE bin or libs directory, I’ll try and fix that next week). In the meanwhile, you need patch #6 if you want to build Amarok on Windows and hear something. Please note I’ve only tried to build it with MSVC2005, not MinGW, not MSVC2008 yet.

Visual C++ 2008 Feature Pack

Sunday, June 29th, 2008

This afternoon I started to add Visual C++ 2008 support to the emerge tool to build KDE 4 on Windows. After a few changes, I tried to build Qt 4.4.0 but it failed.

“Why, oh why?” I wondered. I had previously built Qt 4.4.0 using VC++2008.

Turns out on this computer I had installed the Visual C++ 2008 Feature Pack, which adds some nice stuff (if the Office 2007 look tastes nice to you) but also breaks some stuff (mostly MFC but also some math functions).

Fortunately, it’s easy to fix the issue: just do not #include <xmath> and everything will work fine. As the same codebase has to work with many other compilers, I cannot just get rid of that line of code: I need to #if-case it for VC++2008 with Feature Pack.

Unfortunately, there is no easy way to check for “VC++2008 with Feature Pack”. Sure, you can check for VC++2008 by checking _MSC_VER >= 1500. Easy. Unluckily, the only way to check for the Feature Pack is to check _MFC_VER (check you have MFC 9.0.30411 instead of 9.0.21022), which is only defined if you #include <afxver_ .h>. Of course that file #includes many other files, which means some ugly, confusing problem is waiting to happen.

How dumb can you be, Microsoft? Why aren’t you changing _MSC_VER, too, and make my life easier?

Building Log4CXX 0.10.0 on Windows

Tuesday, April 29th, 2008

Apache Log4CXX is a logging framework for C++ patterned after Apache log4j. It also happens to be quite difficult to build on Windows if you are using Microsoft Windows SDK 1.0 (AKA Microsoft Platform SDK 6.0). If you are building software for Windows Vista or Windows Server 2008, or using Visual C++ 2008, you are using Windows SDK 1.0.

The reason Log4CXX 0.10.0 is hard to compile with Windows SDK 1.0 is a bug in APR 1.2.12 (the latest version available as of this writing) and a bug in Windows SDK 1.0 itself (a preprocessor redefinition due to including twice a header file). Here comes the recipe in case you want to build the stuff yourself:

  1. Download APR 1.2.12 and extract it. Rename to apr.
  2. Download APR Util 1.2.12 and extract it. Rename to apr-util.
  3. Download Log4CXX 0.10.0 and extract it
  4. Download GNU Sed and install it
  5. Open cmd.exe and run %PROGRAMFILES%Microsoft Visual Studio 9.0VCvcvarsall.bat
  6. Apply the apr-1.2.12-win32.patch patch to fix bug 40398 in APR 1.2.12 (this step is not needed if you are using APR 1.2.13)
  7. Apply the log4cxx-0.10.0-vc90-support.patch patch
  8. Enter directory apache-log4cxx-0.10.0
  9. Execute configure.bat
  10. Execute configure-aprutil.bat
  11. Open the log4cxx.dsw solution When asked to convert the solution to VC++9, click Yes to All.
  12. Right click on Solution log4cxx and select Build solution

Guademy, day 1

Saturday, April 26th, 2008

I’m at Valčncia, Spain for Guademy 2008.

Guademy is a combined Gnome + KDE conference, hence the name (Guadec + aKademy), where developers of both desktops (actually every free desktop developer is invited) try to improve collaboration. IMHO it should be renamed to “Freedesktop.org Conferences” because that’s what it actually is.

I’ve seen some frienly faces I knew from other FLOSS events (Aleix Pol, Rodrigo Moya, Carlos Garnacho, Will Stephenson) and I’ve met people I had only read so far (Jos Poortvliet, Holger Freyther). There are some people that were not under my radar, too (Richard Hughes, Vincent Untz).

Yesterday we had talk about QtWebkit by Holger. He tried to show us how good Qt integration with Webkitwas. But he failed. Miserably. It’s not good. It’s AMAZING. Thanks to QtWebkit, he was able to wrote a browser with tabs, cookie management, bookmarks and plugin support in 7800 (seventy eight hundred) lines of code. In five days. The only thing missing was SSL certificate management. Awesome. I provided live translation to Spanish, for non-English speaks.

In the afternoon we had a couple of talks about FreeDesktop.org by Rodrigo, Will and Vicent. In the end, I think the problem with FreeDesktop.org is Gnome and KDE are just suggesting, instead of strongly demanding, their developers to work together.

After that, Aleix talked about KDevelop 4 and demoed it. I have to say I’m gratefully surprised by its progess. Last time I tested it (like 5 months ago), it was totally useless. Currently it works and it works reasonable well. I may start using it soon.

After so much talk, we were quite tired and hungry and went to Los Bestias (“The Rudes”) for dinner. It’s not the typical Spanish restaurant, it’s a “funny restaurant”: the bartender threw (literally) salted peanuts all over the our table, they brought us urinaries with beer and sangria, etc. It was quite funny, IMO.

There are two more days of Guademy, I’ll post more tomorrow.