You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per `man 3 uuid`, the correct include is `<uuid.h>`, and correspondingly
the util-linux build system installs the uuid.h file to
`$(includedir)/uuid/` and uuid.pc adds `-I${includedir}/uuid` to the
dependency Cflags.
Including it as `<uuid/uuid.h>` simply fails altogether. The exception
is if, by coincidence, the libuuid includedir happens to be the same as
one of the compiler's own internal include directories... which is
pretty common if that is `/usr/include`. In this case, `<uuid/uuid.h>`
fails to be found in the uuid dependency's export directories, but the
compiler picks up a copy in its builtin search path.
In other cases, such as when util-linux is compiled into a custom prefix
and added to the PKG_CONFIG_PATH, it either:
- fails with missing header errors, if libuuid-dev is not installed
- seems to succeed, but compiles against a different version of the
headers than the library that is linked to, resulting in potentially
various problems from bizarre linker errors, to subtly broken
incompatible symbols that crash, or corrupt the results
The problem is even worse if you try to use util-linux as a subproject
dependency fallback. In this case, `<uuid.h>` is correctly exported, but
there is no disk location for `<uuid/uuid.h>` and absolutely no way to
generate such a location in the builddir. This completely prevents the
use of subproject fallbacks.
Once the header include is renamed, it is revealed that the example and
test executables don't correctly build as they depend on the full public
interface of libnvme, which includes the public compile interface of
libuuid due to `libnvme.h` including `uuid.h`. Update all executables to
depend on the full public interface of libnvme_dep instead of simply
linking to the library name on its own.
0 commit comments