On Ubuntu, I tend to run up against link errors for libraries installed under /usr/lib/x86_64-linux-gnu/<libname>, which doesn't seem to be searched by default. In the latest example, I tried to use the Python binding of fswatch, which complains undefined symbol: fsw_init_library because the fswatch package installs the shared object under /usr/lib/x86_64-linux-gnu/libfswatch and Python (which seems to rely on gcc) doesn't search it.

I could hard-code a flag to add that directory to the search path like below, but this seems very brittle, non-portable, and just plain wrong.

if sys.platform == 'linux':
    os.setenv ('LD_LIBRARY_PATH', '/usr/lib/x86_64-linux-gnu/libfswatch')

This quickly becomes pretty complicated when I want to use LD_LIBRARY_PATH for other purposes as well, or support non-x86_64 platforms as well, have more than one dependency suffering this problem, and so on. Worse still, this incantation differs quite a bit depending on the toolchain: the code above is for Python; Makefile+gcc would need something else; cmake would probably want another, and so on.

Is there a better way of handling this, which avoids such platform-, package-, and tooling-specific cruft? What's the "right" (intended) way of bringing libraries like this into scope, whose package doesn't care to put it on library search paths? Is there a magic script that would set up environment variables the right way? Is there a setting I'm missing to "enable" these kinds of libraries? Something like pkg-config would be sufficient, but fswatch doesn't ship with a pkg-config .pc file. I've taken up fswatch as an example here, but this is not the first time I got annoyed with this issue (though I can't recall specifics of past incidents).

1 Answer 1


There are two aspects to this.

The first is runtime library resolution; this is what LD_LIBRARY_PATH configures. The cleanest way to deal with this sort of situation is to create a file in /etc/ld.so.conf.d, pointing to the directory containing the library:

echo /usr/lib/x86_64-linux-gnu/libfswatch | sudo tee /etc/ld.so.conf.d/fswatch-x86_64-linux-gnu.conf
sudo ldconfig

The second is build-time resolution; there’s no single “best” solution for this, a pkg-config file is about as good as you’ll get but your builds will obviously need to know that they should refer to that.

  • ldconfig does provide an alternative, but the problem with that is it requires action on the part of the user (other than installing fswatch). If I publish my code, I'd have to say in the README "on Ubuntu, you have to configure ldconfig to use this software", which is a non-starter. The user will have to have root access, know how to configure ldconfig, know which directory fswatch installs libraries in, etc, etc. That seems way too inconvenient to be the "right" way to use this library.
    – Jun Inoue
    Commented Jun 29, 2022 at 1:06
  • If you expect the user to install the fswatch package, they have to be root anyway, and you can provide the exact commands to run. ldconfig is the right way to deal with this, but it’s supposed to be set up by packages providing libraries, not packages consuming them, so I understand your frustration. I wanted to avoid making the answer specific to fswatch, but in this case you’re having to deal with the maintainer’s decision to make the library private. Commented Jun 29, 2022 at 9:18
  • Ooooh, so this library is supposed to be unusable. I missed that bug report. That explains a lot of things, like why I have this kind of problem for only a few packages. That's kinda sad, but this and your point about ldconfig clarifies the situation quite well for me. Thanks.
    – Jun Inoue
    Commented Jun 30, 2022 at 13:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .