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).
