dub
dub copied to clipboard
dlang
pkg-config usage is flawed
System information
ubuntu 22.04 latest dub
Bug Description
The use of pkg-config is unituitive and leads to extremely confusing behavior. When you use pkg-config, there is no guarantee that the package found is actually for the libraries desired.
In my instance, I want to link against systemd, the correct libs directive is:
"libs" : ["systemd"]
On a system that contains pkg-config, this will FAIL to link, because pkg-config --libs systemd returns a blank string. On a system with pkg-config not installed, then the proper -lsystemd is passed to the linker, and it works.
The problem here is that pkg-config found a package file that is not related to the library in question. To fix on a system with pkg-config, you must specify:
"libs": ["libsystemd"]
However, this will fail to build on a system without pkg-config, since -llibsystemd will not work.
How to reproduce?
Create a program which uses libsystemd.so
On a system with libsystemd-dev installed, but not pkg-config: using "systemd" links, using "libsystemd" fails to link.
On a system with libsystemd-dev installed, and pkg-config: using "systemd" fails to link, using "libsystemd" links.
Expected Behavior
Using "systemd" as the libs directive requests the library "libsystemd.so", and should link, regardless of whether pkg-config is installed.
After reading about pkg-config and its use in meson, I would suggest a new llibs directive. That will not do any extra resolution.
Also, pkg-config should be available on all platforms, not just Posix.
Honestly, I think it should be the other way around. If you polled 10 experienced D devs, 9 of them would have no idea that dub does anything other than translate libs to the appropriate OS linker flags.
My preference (if we were designing from scratch) is that there would be a pkg-libs directive, and a libs directive, and pkg-libs would fail if either pkg-config is not installed or it has no package file for the given name. libs should just do the translation into the correct linker flags.
The extra clever effort here is very harmful, because when it doesn't work, it just looks like a bug. Build systems should be clear and simple.
libsshould just do the translation into the correct linker flags.
How do you define what "correct" is ?
For posix systems, using foo would mean -lfoo is passed to the linker. On Windows, it means foo.lib is passed to the linker. This is standard fare for linking.
Note that this is what dub currently does if pkg-config isn't found.
On a system that contains pkg-config, this will FAIL to link, because pkg-config --libs systemd returns a blank string.
On that situation, it should actually keep the original lib IMO.
On a system with pkg-config not installed, then the proper -lsystemd is passed to the linker, and it works.
This will lead to the same behavior from the above description.
The problem here is that pkg-config found a package file that is not related to the library in question. To fix on a system with pkg-config, you must specify:
On that issue specifically, this looks more like an edge case than the other places. I have seen pkg-config actually being really useful for libs such as OpenGL and X11. Besides that, pkg-config does creates a problem because the user is not aware of what is actually happening. My only suggestion is having the transform information being printed when having a linker error.
For posix systems, using foo would mean -lfoo is passed to the linker. On Windows, it means foo.lib is passed to the linker.
Passing -lfoo vs foo.lib between windows and linux isn't quite right, ain't it? Since foo.lib you're specifying a file and that is not supposedly to be searched in the linker paths.
