[LU-12720] Issue with 'blkid' when configuring/building Lustre Created: 30/Aug/19 Updated: 25/Nov/19 Resolved: 07/Sep/19 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.13.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Sebastien Buisson | Assignee: | James A Simmons |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | build | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
Due to patch "LU-9897 build: use pkgconf for detecting libblkid" recently landed in master (https://review.whamcloud.com/35531), it is quite complicated to understand which package to install in order to comply with 'blkid' requirements. Indeed, the error message says: configure: error: Package requirements (blkid) were not met: No package 'blkid' found but the actual name of the package is libblkid-devel on CentOS and libblkid-dev on Ubuntu. Moreover, this check for blkid should not be carried out when building client only (--disable-server configure option). |
| Comments |
| Comment by Patrick Farrell (Inactive) [ 30/Aug/19 ] |
|
Minh, You suggested maybe we're using the macro wrong - Do you have a suggestion for this? James, As it stands, this is really bad - We can't have configure say "you need blkid" and have that mean "libblkid-devel", particularly when "blkid" is also the name of a related command. So the user experience is "OK, configure says I need blkid, let me search for that... but I have blkid installed, what on earth", followed (in my case at least) by banging in to walls for a while until you just start installing every blkid related package you can find. |
| Comment by James A Simmons [ 30/Aug/19 ] |
|
pkgconf is a pretty standard tool used in my projects. Its also more flexible in that it can handle packages in non standard locations i.e /usr/local. Also using pkgconf also ensures all the proper libraries are linked. I have seen some libraries missed before when linking manually. pkgconf is independent of the package name since package names can vary from platform to platform as you shown above. So 'pkg-config --libs --cflags blkid' will work on any platform. Give it a try. I had a discussion with Andreas about this. So with the original check blkid was always checked and if it failed the build system would go on its way. I found this out the hard way with llverdev while testing with an image with no libblkid installed. So the patch that landed fixed that issue. Andreas has suggested that we remove using libblkid from llverdev. Now mount for ZFS does use blkid but the ZFS packages do pull in blkid. So in theory we can depend on ZFS doing it for us but I wonder if we should still make sure blkid is pulled in? BTW we have the same issue with e2fsprogs |
| Comment by James A Simmons [ 30/Aug/19 ] |
|
Patrick I just posted that Sebastein how pkgconf works. He didn't understand it. Please read https://autotools.io/pkgconfig/pkg_check_modules.html and https://www.freedesktop.org/wiki/Software/pkg-config/. What this exposed is that people never realized that the autoconf test for blkid was always failing if libblkid was not installed and it just went on its merry way. I saw this in my local test failures. I harden this test which now makes people realize libblkid are NOT INSTALLED in their images. The test is doing what its suppose to do. |
| Comment by James A Simmons [ 30/Aug/19 ] |
|
I will fix this up. The problems I see is that llverdev is built on the client but is only needed for the server. As Andreas suggested we can remove libblkid usage for llverdev completely. We have the same issue with e2fsprogs. e2fsprog is missing from the spec / deb files but sanity test 130 for fiemap needs e2fsprogs. Additionally its needed for ldiskfs I believe as well. Another example of break I have know for some time is selinux. configure will build lustre without libselinux support but if you install it the spec file has a hard dependency and it fails to install. I was hoping to sort these kinds of failures out. |
| Comment by Patrick Farrell (Inactive) [ 30/Aug/19 ] |
|
James, I think Sebastien and I do understand how pkgconfig works, and I think you've missed my point. None of what you're saying is the problem here - The problem here is the output says it can't find the package "blkid", but something named blkid is already installed, and instead we need to install libblkid-devel. That's super confusing and has already cost several of us a bunch of time banging around trying to figure out what's going on. Minh pointed out the actual issue seems to be a bug in the package metadata for blkid, where the pkconfig metadata for libblkid-devel gives the package name as "blkid", which is kind of crazy. (Particularly since there is already something else named blkid.) Maybe we can fix this confusion by adding an extra message in our config stuff to make up for the bad metadata elsewhere, something to say "pkconfig blkid is provided by libblkdid-devel"? But I don't think having Lustre say "you need the blkid package" when you actually need something else is OK. |
| Comment by Patrick Farrell (Inactive) [ 30/Aug/19 ] |
|
Ok, scratch that - Andreas just said blkid isn't necessary for anything and we can just remove it. He's got a patch. (Just posting here to save us time arguing about it |
| Comment by James A Simmons [ 30/Aug/19 ] |
|
Ah I see what you are saying. Sorry I misunderstood. The command is PKG_CHECK_MODULES(prefix, list-of-modules, action-if-found, action-if-not-found) so it should be of the format: AS_IF([test "x$enable_dist" = xno], [ PKG_CHECK_MODULES(blkid, [blkid], [ AC_MSG_RESULT[libblkid development packages found], [ AC_MSG_ERROR[Please install the libblkid development packages] ])]) |
| Comment by Andreas Dilger [ 03/Sep/19 ] |
|
Patch https://review.whamcloud.com/36010 "LU-9897 utils: remove dependency on libblkid" removes the changes added in "LU-9897 build: use pkgconf for detecting libblkid" since libblkid is not actually needed for llverdev to work. |
| Comment by Sebastien Buisson [ 03/Sep/19 ] |
|
So that eliminates the root cause of the problem described here. This ticket can be closed, thanks. |