Automatically find dependencies on standard locations on BSD systems

[nomis]

Meson currently includes in /usr/local/lib in the get_library_dirs() function but doesn't use this path when trying to find dependencies. It is noted that this is "probably Debian/Ubuntu specific". There's no checking of /usr/local/include anywhere.

For Boost on Windows it will attempt to search various paths in C:\ (this is probably wrong because the system may not be installed on C:\), but on BSD systems I have to set BOOST_ROOT.

I think Meson should include the standard locations of packages on BSD systems when searching for dependencies:

• FreeBSD: /usr/local
• OpenBSD: /usr/local
• NetBSD: /usr/pkg
• DragonFlyBSD: /usr/local

These are not simply the default locations when manually installing dependencies (that would be an exercise for the user in specifying the correct location), they're the standard locations when using the OS-provided package manager to install packages from a predefined list. Similar to how Debian/Ubuntu systems install packages from a predefined list to /usr.

[andy5995]

Thanks @nomis, I used your patch earlier tonight (on MacOS though, not BSD... )

[andy5995]

Apparently related to (or a duplicate of) #3929

[andy5995]

@nomis @emersion You may want to test this branch that @eli-schwartz is working on. I think it's supposed to take care of this.

[nomis]

Please stop trying to consider this to be a duplicate of difficulty finding libintl. It is not.

The boost dependency has /usr/local included but not /usr/pkg; are we to wait until every dependency has special code to handle all operating systems?

[emersion]

My projects don't need libintl. Instead, they need /usr/local/lib to be included to the default search paths on FreeBSD, or else the required dependencies (e.g. iniparser) cannot be found.

Also /usr/local/include should be included in the isystem paths, otherwise the compiler will produce warnings for headers coming from third-party dependencies.

[eli-schwartz]

My suggested code for handling libintl will use the default search path of /usr/lib because it will act like cc.find_library().

It is indeed completely unrelated to (and will not fix) any /usr/local/lib problems on BSD systems.

[mqudsi]

Note that #2239 was incorrectly closed and is (still) affected by this.

[rgommers]

I just ran into this as well. It looks like in the activity around the linked issue gh-2239 , the /usr/local/ location was explicitly added to the Boost dependency, but it's not specific to Boost - the pkg package manager installs all its packages to that location. E.g. when implementing a system dependency for libblas:

$ pkg install blas
$ pkg list blas
/usr/local/lib/libblas.a
/usr/local/lib/libblas.so
/usr/local/lib/libblas.so.3
/usr/local/lib/libblas.so.3.11.0
/usr/local/libdata/pkgconfig/blas.pc
/usr/local/share/licenses/blas-3.11.0_1/BSD3CLAUSE
/usr/local/share/licenses/blas-3.11.0_1/LICENSE
/usr/local/share/licenses/blas-3.11.0_1/catalog.mk

$ # Now run a build which calls `clib_compiler.find_library('blas')` inside BLASSystemDependency
...
Pkg-config binary for machine 1 not found. Giving up.
Running compile:
Working directory:  /tmp/cirrus-ci-build/build/meson-private/tmpqb4fbjfd
Code:
 int main(void) { return 0; }
-----------
Command line: `c++ /tmp/cirrus-ci-build/build/meson-private/tmpqb4fbjfd/testfile.cpp -o /tmp/cirrus-ci-build/build/meson-private/tmpqb4fbjfd/output.exe -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -Werror=implicit-function-declaration -Wl,--start-group -lblas -Wl,--end-group -Wl,--allow-shlib-undefined` -> 1
stderr:
ld: error: unable to find library -lblas
c++: error: linker command failed with exit code 1 (use -v to see invocation)
-----------
Run-time dependency blas found: NO (tried pkgconfig and system)

libblas.so is installed in its default location by the system package manager, and it's not being found. The issue description proposes the correct solution here I believe - add those OS-specific paths to the default library search paths to make find_library work for system dependencies.

Now this is not a blocker for me right now, because it's easily worked around by pkg install pkgconf; the pkg-config based dependency detection works fine. But it's still annoying that the system dependency doesn't work. I've also seen a suggestion in one of the other issues where this topic was discussed to add extra_dirs: /usr/local/lib to the find_library call, but that seems like the wrong solution because nothing about this is specific to a particular dependency.

[rgommers]

In gh-7746 it's pointed out that this could also be solved on the distro side (e.g., https://wiki.freebsd.org/WarnerLosh/UsrLocal). But it doesn't seem like that is moving.

[eli-schwartz]

I guess it sort of depends on whether we view it as "working around a system bug" or "disrespecting the intended policy of the system".

[rgommers]

Hmm, I am not too familiar with BSD politics, but I can't see much of a justification for "intended policy". Seems more like a bad situation with just a lack of coordination to improve on the status quo, if I read the first paragraphs of the page linked two comments up.

Either way, fixing it just for the Boost dependency in Meson but not for all dependencies is surely inconsistent?