What package does this file belong to?

If you’re messing playing around with some code, you probably have reached that point where you copy code from a tutorial but it doesn’t compile because your system is missing an include file. And you don’t have a clue of where to look for it, or maybe you have a clue but the package maintainers thought of a different naming for the package and it’s very different from what you suspect it is.

But lament no more, for I just found a nifty utility for Debian based systems such as Ubuntu that is proving already very useful: apt-file. And I wonder how could I survive without it before. It’s very simple to use: enter apt-file search the_missing_include.h in your favourite terminal session, and it will let you know which package(s) contain that cheeky .h.

For example, I was trying to compile a basic sample snippet for testing ALSA, and it has an #include <alsa/asoundlib.h> right in the first line. I crossed my fingers and hoped for that include to be already on my system, but I got this error instead:

alsa_test.c:1:28: error: alsa/asoundlib.h: No such file or directory

Where could the file reside? I guessed it could be in alsa-dev, but apt-file quickly proved me wrong:

$ apt-file search alsa/asoundlib.h
libasound2-dev: /usr/include/alsa/asoundlib.h

So that’s it, asoundlib.h is in the package libasound2-dev.

Of course, you can install apt-file with apt-get or with synaptic package manager, as you wish. This is apt-cool! 😀

5 Replies to “What package does this file belong to?”

  1. apt-file does not only search in your installed packages, but in you whole package cache, thus it may take a long time specially if you’ve enabled extra sources and/or added some crowded ppas (Personal Package Archives).
    In some occasions you’ve alreay have the missing file, but, as you said, don’t know where it’s laying. dpkg can help in those situations, simply type

    defo:~$ dpkg -S glew.h
    libglew1.5-dev: /usr/include/GL/wglew.h

    If you are not lucky enough to have dpkg in yout system 😛 there’s also a simpler approach of finding stuff called locate (mlocate package under ubuntu), a locate -i would be enough in most cases.

    Both locate and dpkg need to have “seen” the file, so it must be installed/compilled/uncompressed.
    apt-file it’s the best though sometimes these simple applications can solve situations when the files are not where your distutils/makefile/cmake/scons/rake or just sources thought they would be.

  2. Ohh didn’t know dpkg could be used like that. I had used ‘locate’ previously, though. What I like about apt-file is that it doesn’t need to “have seen” the file, and lets me know which package should I install in order to obtain that file. When I’m totally sure the file is in my system, I normally use locate – although I might use dpkg too now 😀

    Thanks for the idea!

  3. pkgfile do the same on ArchLinux =) (you can find pkgfile in the pkgtools package for ArchLinux =)


    PD: if you want to use the `locate’ command, run `updatedb’ as root first this for update the file-list-db =)

    [sorry if my English sucks]

  4. dlocate does the job too, with the same qualifier as dpkg, but is faster.

Comments are closed.