Bug 1658630 - Inconsistency in libraries used by libdevmapper-event and dmeventd
Summary: Inconsistency in libraries used by libdevmapper-event and dmeventd
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Zdenek Kabelac
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1650686
TreeView+ depends on / blocked
 
Reported: 2018-12-12 15:07 UTC by Marian Csontos
Modified: 2021-09-07 11:54 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.03.02-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1650686
Environment:
Last Closed: 2019-06-14 01:38:10 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-19852 0 None None None 2021-09-07 11:54:29 UTC

Description Marian Csontos 2018-12-12 15:07:18 UTC
device-mapper-event-devel dropped dependency on libdevmapper, and now there is an inconsistent use of libraries.

- dmeventd is linking with internal library,
- libdevmapper-event.so is not linking any library.

Both dmeventd and libdevmapper-event.so should use same libraries, and given the libdevmapper-event.h requires some structures from libdevmapper it should use public API, instead of internal ones.

+++ This bug was initially created as a clone of Bug #1650686 +++

Description of problem:
When attempting to rebuild the 'vdo' RPM, the build fails.  Initially it is due to a missing file of libdevmapper.h.  When the BuildRequires: is added to include device-mapper-devel, the build then fails when linking, needing an additional reference to devmapper.

Version-Release number of selected component (if applicable):
device-mapper-event-devel-1.02.153-1.el8
vdo-6.2.0.239-35.el8 (or https://github.com/dm-vdo/kvdo/tree/6.2.0.239)

How reproducible:
100%

Steps to Reproduce:
1. Install device-mapper-event-devel on RHEL8
2. Clone https://github.com/dm-vdo/vdo
3. Run make

Actual results:
First (with the missing dependency):
cc -fPIC -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=z13 -mtune=z14 -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -g -O3 -fno-omit-frame-pointer -Wall -Wcast-align -Werror -Wextra -Winit-self -Wlogical-op -Wmissing-include-dirs -Wpointer-arith -Wredundant-decls -Wunused -Wwrite-strings    -std=c99 -Wbad-function-cast -Wcast-qual -Wfloat-equal -Wformat=2 -Wmissing-declarations -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wswitch-default  -pedantic  -I../base -I../../uds -Wno-write-strings -DINTERNAL -DCURRENT_VERSION="\"6.2.0.273\"" "-DPLUGIN_NAME=\"libdevmapper-event-lvm2vdo.so\""   -c -MMD -MF .deps/vdodmeventd.d.new -MP -MT vdodmeventd.o -o vdodmeventd.o vdodmeventd.c
vdodmeventd.c:32:10: fatal error: libdevmapper.h: No such file or directory
 #include <libdevmapper.h>

Second (with the missing link arg):
cc -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  vdodmeventd.o libuser.a ../base/libvdo.a ../../uds/libuds.a -ldl -pthread -lz -lrt -lm -luuid "-ldevmapper-event" -o vdodmeventd
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_get_uuid'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_log_with_errno'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_set_major'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_set_uuid'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_asprintf'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_run'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_create'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_destroy'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_get_name'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_set_name'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_set_minor'
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/libdevmapper-event.so: undefined reference to `dm_task_get_info'
collect2: error: ld returned 1 exit status

Expected results:
Successful build.

Additional info:
At some point, some of the symbols from device-mapper-event-devel moved to device-mapper-devel.

--- Additional comment from Andy Walsh on 2018-11-16 20:47:16 UTC ---

When vdo-6.2.0.239 was originally built, the device-mapper package installed was device-mapper-event-devel-1.02.150-1.el8.

So at some point between 1.02.150 and 1.02.153, things were moved around.

I attempted to reproduce this on Fedora Rawhide, Fedora 29, and Fedora 28 without success.  So in this case, rhel8 seems to be ahead of the others for now.

--- Additional comment from Andy Walsh on 2018-11-28 20:16 UTC ---

In addition to adding the "BuildRequires: device-mapper-devel" to the spec, this patch is also necessary.

--- Additional comment from Marian Csontos on 2018-12-10 16:02:24 UTC ---

Is this actually a bug?

I have seen a -ldevmapper used in an earlier RHEL8 brew builds, for example here:

  http://download.eng.bos.redhat.com/brewroot/vol/rhel-8/packages/vdo/6.2.0.273/9.el8/data/logs/x86_64/build.log

And also device-mapper-devel is installed:

  http://download.eng.bos.redhat.com/brewroot/vol/rhel-8/packages/vdo/6.2.0.273/9.el8/data/logs/x86_64/root.log

So, I wonder, have you accidentally dropped a dependency?

--- Additional comment from Marian Csontos on 2018-12-10 16:06:10 UTC ---

Oh, that's a patched build, right?

--- Additional comment from Andy Walsh on 2018-12-10 16:06:39 UTC ---

Yes.

If I rebuild the 6.2.0.239 version with no changes, the package will not build due to the issues mentioned in the original description.  Version 6.2.0.273-9.el8 has the changes to work with the current state of things.  It is currently only applied to the RHEL8 build and nowhere else, since it doesn't seem to affect any of the Fedora releases (or it hadn't when I filed the bug, I don't know if that is still the case).

The changes I had to apply to 6.2.0.273-9 to build is noted in Comment 2.

--- Additional comment from Marian Csontos on 2018-12-10 16:26:31 UTC ---

The RPM somehow lost a dependency on `pkgconfig(devmapper)`. I will look into that tomorrow.

--- Additional comment from Marian Csontos on 2018-12-11 14:11:24 UTC ---

So, the issue is, libdevmapper-event.so in 2.03 is using internal device_mapper library, but is not linking it. I will fix this.

Also, the original error suggests you are using devmapper library, but are not depending on that:

    vdodmeventd.c:32:10: fatal error: libdevmapper.h: No such file or directory

The libdevmapper-event required libdevmapper, but it does not anymore.

So you should either drop the libdevmapper.h from your code, or add BuildRequire: device-mapper-devel (as you did).

--- Additional comment from Andy Walsh on 2018-12-11 16:23:06 UTC ---

Thanks.  I will make sure to keep the new 'BuildRequires: device-mapper-devel'

Comment 2 Zdenek Kabelac 2018-12-17 15:04:14 UTC
I've provided number of patches towards more correct linking and converted   'dmeventd' to be a regular user of original libdevmapper library (as it is basically libdevmapper tool like dmsetup).
As dmeventd supports external users - it has to be linked with external libraries.

Patchset starts about here:

https://www.redhat.com/archives/lvm-devel/2018-December/msg00048.html

Comment 3 Marian Csontos 2018-12-17 15:34:30 UTC
Hi Rob, could we get an ACK for this not-really-a-"Rebase" ?


Note You need to log in before you can comment on or make changes to this bug.